Re: [Qemu-devel] Re: [RFC/PATCH] elfload: add FDPIC support
On Mon, Jan 24, 2011 at 08:34, Stefano Bonifazi wrote: Is FDPIC something different than simply PIC code (position independent code)? FDPIC ELF is the ELF PIE format used on NOMMU systems so that both the text and data regions may be located anywhere. it is the only ELF format supported under NOMMU systems. I am also trying to fight with the problem of changing the starting address of target code for qemu-user, and I was just moving into the option of using PIC target code .. but the original qemu-user load_elf_binary does not work on them.. and I was just about to try to edit it.. i dont believe my patch accomplishes that in any way. i will need to force all files to be loaded at a higher address than zero for the Blackfin arch (as the first ~4KiB is reserved for the ABI), but that is independent of FDPIC ELF support. -mike
Re: [Qemu-devel] Re: [RFC/PATCH] elfload: add FDPIC support
On 01/24/2011 08:11 PM, Mike Frysinger wrote: On Mon, Jan 24, 2011 at 08:34, Stefano Bonifazi wrote: Is FDPIC something different than simply PIC code (position independent code)? FDPIC ELF is the ELF PIE format used on NOMMU systems so that both the text and data regions may be located anywhere. it is the only ELF format supported under NOMMU systems. I am also trying to fight with the problem of changing the starting address of target code for qemu-user, and I was just moving into the option of using PIC target code .. but the original qemu-user load_elf_binary does not work on them.. and I was just about to try to edit it.. i dont believe my patch accomplishes that in any way. i will need to force all files to be loaded at a higher address than zero for the Blackfin arch (as the first ~4KiB is reserved for the ABI), but that is independent of FDPIC ELF support. -mike I don't understand.. what is the difference between pie binary for pcc and for your architecture? 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? Thank you! Regards, Stefano B.
Re: [Qemu-devel] Re: [RFC/PATCH] elfload: add FDPIC support
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
Re: [Qemu-devel] Re: [RFC/PATCH] elfload: add FDPIC support
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.
