Re: [Qemu-devel] Re: [RFC/PATCH] elfload: add FDPIC support

[Stefano Bonifazi <stefboombastic@gmail.com>]

On 01/24/2011 10:27 PM, Mike Frysinger wrote:
> On Mon, Jan 24, 2011 at 16:06, Stefano Bonifazi wrote:
>> I don't understand.. what is the difference between pie binary for pcc and
>> for your architecture?
> as i said, i think this is all irrelevant to what you want to do.  but
> since you asked and i feel like writing ...
>
> i have no idea what "pcc" is.  there are really two stark differences
> between FDPIC ELF and a PIE ELF on say x86.  since the data/text
> sections can be relocated independently of each other, the PIC cannot
> assume a fixed offset between its text and GOT.  so every PLT entry is
> actually two sets of addresses -- the function address and the
> function's GOT address.  the other big difference is that an FDPIC ELF
> app must first do a little relocation processing of itself as soon as
> it starts ... in order to do so, the kernel provides a loadmap (made
> up of multiple loadsegs) which describes the executable's PT_LOADs
> (the addr encoded in the program header and the addr the chunk was
> actually relocated to) as well as the (optional) executable's
> interpreter's PT_LOADs.
>
>> As far as I understood pie code is independent from addresses, so it should
>> not care if the OS running them would have an mmu at all.. it should be just
>> the task of the dynamic linker to relocate it properly, am I wrong?
> but the PIE code still has fixed offsets between its text and its
> data.  so FDPIC ELF is even more flexible than a PIE ELF.
> -mike
Thank you very much!
As a student, understanding how things work is even more precious than 
making things work ;)
You know?  I was just trying to figure out today how the code could 
locate the .got in x86 when relocation is needed..
I am studying ELF and relocation now, reading all possible material 
online, but I did not find yet about the fixed offset!

PPC stands for PowerPC.

Now also your code is much clearer for me, though not useful in my case..

Thank you again!
Best regards!
Stefano B.