weird elf header issues, is it binutils or my linker script?

Segher Boessenkool segher at kernel.crashing.org
Wed Apr 3 02:07:11 EST 2013


>>> SECTIONS
>>> {
>>> /* Read-only sections, merged into text segment: */
>>> PROVIDE (__executable_start = 0xf2000000); . = 0xf2000000 +
>>> SIZEOF_HEADERS;
>>> .interp : { *(.interp) } :text :interp
>>> <snip>
>>> }
>>>
>>> So I'm wondering...is this something wrong with our linker script,
>>> or is there a bug in our binutils? I'm no linker expert, but the
>>> interpreter sections in the script seem to match the binutils
>>> documentation that I found and I don't see anything that would be
>>> messing with the length.
>>>
>>> Any suggestions on where to look?
>>
>> It looks like your .interp input section lacks the required
>> zero-termination.
>
> That's the weird thing....the actual interpreter string "/lib/ld.so. 
> 1" is in fact null-terminated, but the length in the elf headers is  
> incorrect (0x30 instead of 0xd) and so when the kernel checks the  
> last character in the array it sees a nonzero value.
>
> What I don't understand is where the "/lib/ld.so.1" string is  
> coming from and how the length gets set to the invalid value.

It comes from the .interp input sections, i.e. the .interp sections in
the .o files you linked together.  Perhaps you have more than one of
those?

Run ld with the -M option to tell you what it does; run readelf -xN
where N is the section number of .interp to figure out what is actually
in there.

Your PT_INTERP has a memsz < filesz, which is curious to say the least.
I suspect there are multiple zero bytes in there; this is not valid in
an ELF file.  It would be good if the linker complained about that.
The kernel loader is correct in refusing it (if that is what it is
doing :-) )


Segher



More information about the Linuxppc-dev mailing list