amd64/127276: ldd invokes linux yes

[John Baldwin]

On Sunday 14 September 2008 10:33:47 am Dominic Fandrey wrote:
> John Baldwin wrote:
> > FreeBSD binaries from various releases have been branded in different 
ways.  I 
> > would consider it more of a user error to run ldd on a Linux binary. :)  
You 
> > could maybe add a "IMPLEMENTATION NOTES" section to the manpage that 
explains 
> > how it works and why it will execute any binary using a different runtime 
> > linker.
> > 
> 
> Well, documenting it is much better than the current state. Though in my
> opinion it doesn't matter to the user how it works, but what one expects the
> program to do. And the current behaviour is not what I expected.
> 
> Would you instead accept a patch from me that does a compatibility check and
> bails out if the binary does not use the FreeBSD linker?

It can be hard to determine that.  What happens is that each ELF binary 
includes a path to its interpreter (i.e. the runtime linker).  For FreeBSD 
binaries this can be either /usr/libexec/ld-elf.so.1 or /libexec/ld-elf.so.1 
or the a.out paths (/usr/libexec/ld.so.1 I think).  In the kernel, ABI 
modules hook into exec and when they see a binary they can handle, they can 
choose to overwrite the interpreter path to point it to somewhere else (e.g. 
the Linux ABI uses a path under /compat/linux instead, and the 'freebsd32' 
ABI on amd64 uses /libexec/ld-elf32.so.1).  Any ELF binary that uses one of 
the two ld-elf.so.1 (or ld-elf32.so.1) paths will use the FreeBSD runtime 
linker, regardless of which "OS" the binary is targeted for.  You could maybe 
hardcode the list of interpreter strings to check for, but that wouldn't be 
completely foolproof.  You could have an ABI that is fine with using the 
FreeBSD linker even though its native "OS" uses a different interpreter path 
(though that is unlikely).  In that case the kernel module would be rewriting 
the interpreter path to be the FreeBSD ld-elf, but ldd would have no clue.

> The "IMPLEMENTATION NOTES" would still be nice to have, though. It's always
> a nice read to get an idea on how something works. And I find code much
> easier to decipher if I already know how it's supposed to do something. At
> least much easier than the opposite way, trying to glimpse how something
> works from the code.
> 
> Regards
> 



-- 
John Baldwin