1748148 Members
3865 Online
108758 Solutions
New Discussion юеВ

Re: ELF Loading

 
SOLVED
Go to solution
Dan Fego
New Member

ELF Loading

I've recently been looking into how HP-UX loads ELF files into memory, and noticed some oddness compared to some other systems, at least on the surface, in how the memory segments are mapped.

As an example using a shared object (.so), it would seem that with an abridged segment header table like so:

Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x04000000 0x00000000 0x007f0 0x007f0 R E 0x10
LOAD 0x010000 0x40010000 0x00000000 0x00068 0x00080 RW 0x10

It would appear that two mappings should be created in memory. The first should be lower and have read/execute permissions, and the second should appear (0x40010000 - 0x04000000) after the first begins, and have read/write permissions. However, what actually seems to happen is that two mappings get created, but the one lower in memory has read/write, and the higher one has read/execute.

I understand that private and shared mappings seem to get shoved into different regions of memory, but this still doesn't account for the way the ELF is supposedly laid out according to its program headers (shown above). On Linux, for example, the memory regions are both contiguous and properly ordered in relation to the segments in the ELF file.

What I'm asking is for some explanation of what's going on here. Does the system loader just go through a bunch of effort to change everything in such a way that this works out? That seems like way more work than should be necessary. A position-independent ELF should already have everything laid out so that loading is relatively straightforward (minus relocations) insofar that everything is laid out properly, relative to everything else. But with HP-UX this doesn't seem to be the case.

Observations made on HP-UX 11i v3, IA-64.
3 REPLIES 3
Dennis Handly
Acclaimed Contributor

Re: ELF Loading

>As an example using a shared object (.so)

The loader doesn't load those, only executables. It is dld.so(5) that mmaps shlibs.

>It would appear that two mappings should be created in memory.

No, up to three, one for BSS.

>the one lower in memory has read/write, and the higher one has read/execute.

That's because the kernel places shared text segments in a special region.

>this still doesn't account for the way the ELF is supposedly laid out according to its program headers.

For shlibs, the virtual addresses in these headers are illusions. The linker lays these out as if they were executables.

>Does the system loader just go through a bunch of effort to change everything in such a way that this works out?

There's no loader here, just dld.so. And yes, everything works out. :-)

>A position-independent ELF should already have everything laid out so that loading is relatively straightforward

Yes, dld asks the kernel to return some "random" address and uses that.

>that everything is laid out properly, relative to everything else. But with HP-UX this doesn't seem to be the case.

There's no "relative to everything else" on HP-UX, each segment is/can be completely independent.
Dan Fego
New Member

Re: ELF Loading

Dennis, thanks for the thorough reply. You've straightened me out a bit, but I'm still a little in the lurch, in particular with the following response:

>There's no "relative to everything else" on HP-UX, each segment is/can be completely independent.

Text and data are held in different segments for each .so loaded. The text is in the read/execute/shared and data is in read/write/private. The text must need to reference the data at some point though, which means that something in the loaded text segment must get relocated... Ah, hold up, moment of clarity -- is that what the .rela.dlt is? Data linkage table, perhaps? Such that all these references to data are handled by the standard relocation process? If that's the case, this just got a whole lot clearer for me.
Dennis Handly
Acclaimed Contributor
Solution

Re: ELF Loading

>The text must need to reference the data at some point though, which means that something in the loaded text segment must get relocated.

No, text segments are read only and can't be modified. So either it is accessed relative to GP or from the linkage table.

>is that what the .rela.dlt is? Data linkage table, perhaps? Such that all these references to data are handled by the standard relocation process?

Yes. If GP relative, no dynamic relocations are needed.