[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pcc-list
Subject:    Re: Generating PIC code
From:       Anders Magnusson <ragge () ludd ! ltu ! se>
Date:       2007-10-13 11:58:08
Message-ID: 4710B2D0.5060306 () ludd ! ltu ! se
[Download RAW message or body]

Hi Gregory,

I think your achievements are really great! :-)

But, because I haven't got any answer yet, I continue to harass
you: do you mind getting an account on the project server and
start checking in your stuff?  :-)

-- Ragge

Gregory McGarry wrote:
>> Joerg Sonnenberger wrote:
>> > On Sat, Oct 06, 2007 at 10:58:06AM +0200, Anders Magnusson wrote:
>> >   
>> >> 1) Early rewriting of trees, so that some references are converted to 
>> >> ebx-relative already
>> >>    when the trees are created.  This must be done in 
>> target-specific code 
>> >> because it it
>> >>    target-dependent. (clocal())
>> >>     
>> >
>> > It would be very helpful to be able to distingish static and hidden
>> > symbols at this point already. Basically hidden in the ELF meaning is
>> > working like static but can be referenced by other modules in the DSO.
>> >
>> > Based on that for each function it should be decided whether it needs
>> > the PIC setup or not. If you optimise all references to global variables
>> > away and you can use IP relative references for the rest, the PIC stub
>> > is unneeded.
>> >
>> > This should be done in target independent code except when the 
>> backend says
>> > that it only PIC or non-PIC.
>> Conversion of a NAME node to something else in the compiler is done in
>> the clocal() routine, which is target-dependent. This is done early, 
>> actually
>> already when the name is found by yacc.  Not that I am an expert in 
>> how pic
>> works on all targets, but I think I know how it works on x86 (and vax 
>> :-).
>>  From my POV it would be rather simple to add the pic code there and then
>> it should 'just work'.  Please correct me if I'm wrong...
>
> Well it could be that simple.
>
> I did the reference rewrite in clocal(), but deferred emitting the 
> prologue and changing the instruction until the backend.  In the 
> backend I keep a list of the relocated symbols and emit the stubs in 
> ejobcode().
>
> But, I now have pcc compiling PPC code and linking against the system 
> shared libraries on OS X.
>
> woot!
>

[prev in list] [next in list] [prev in thread] [next in thread]