IA64 ELF header question...
Does anyone know whether the e_entry field in the IA64 ELF header is equal to the address of the function descriptor of the _start routine or whether it's equal to the address of the _start code? (ie, ._start) Looking at the IA64 kernel and GLIBC sources (the IA64 ABI was a little vague), I'm guessing e_entry is actually the address of the _start code (ie, e_entry = address of ._start).
The reason I ask, is that I'm working on the PPC64 GLIBC port and our ABI states that our e_entry field is equal to the address of the function descriptor for _start. This was fine for statically linked apps. All we needed to change in the kernel was an extra dereference in start_thread to load the actual code address of _start and away we went.
My problem is with dynamically linked apps. The kernel is smart enough to know when it loads ld.so to reloc the e_entry field. The problem is that the function descriptor entries for _start need to be reloc'd too before we can use them. I'd prefer not to touch arch independent code to fix this, but it doesn't look like I have enough info in start_thread to determine whether I need to reloc the function descriptor entries or not before using them. Since PPC64 and IA64 share the use of function descriptors, I thought I'd check with people here on how this was solved for IA64. Anyone have any ideas I can use?
...I guess another option I could try is to change the PowerPC64-ELF ABI to say that the e_entry field holds the address of ._start rather than _start. Although, I'm not sure whether that's possible or not.
Peter
--
Peter Bergner
SLIC Optimizing Translator Development / Linux PPC64 Kernel Development IBM Rochester, MN
[email protected]
Quoted 3 lines
Since PPC64 and IA64 share the use of function descriptors, I thought I'd check with people here on how this was solved for IA64. Anyone have any ideas I can use?
PA-RISC also uses function descriptors. On HP-UX, for both PA-RISC and IA-64, the e_entry field is the address of the code entry point itself, rather than the address of a function descriptor. Our dynamic loader initializes its own gp value, and when it's time for the dynamic loader to call the application's entry point, it knows what the gp value should be, so we don't need a function descriptor.
Cary Coutant
HP-UX Runtime Architect
Quoted 6 lines · Cary Coutant
PA-RISC also uses function descriptors. On HP-UX, for both PA-RISC and IA-64, the
e_entryfield is the address of the code entry point itself, rather than the address of a function descriptor. Our dynamic loader initializes its own gp value, and when it's time for the dynamic loader to call the application's entry point, it knows what the gp value should be, so we don't need a function descriptor.
This looks also to be the case for Linux/IA64 (from what I gathered from looking at the IA64 kernel and GLIBC source). Changing our ABI to match this doesn't look promising, as we're not the only OS using this ABI. This means I'll need to modify the kernel to reloc our function descriptor (FD)
entries. The only problem is, I don't have enough information in start_thread
to know whether I need to reloc the FD entries or not. Seems like I'll need
to place some code in fs/binfmt_elf.c to gather up the information needed
to perform the reloc's in start_thread.
Note I don't really want to reloc the function descriptor entries, just the values I copy out of the entries as I stuff them into my pt_regs struct.
Peter