[lldb-dev] Linux ELF header e_ident[EI_OSABI] value

[Howard Hellyer via lldb-dev]

"Ted Woodward" <ted.woodward at codeaurora.org> wrote on 22/08/2016 21:03:02:

> We don't want to make ELFOSABI_NONE mean Linux. ELFOSABI_NONE is 
> historically ELFOSABI_SYSV, and used by a lot of things. So not all 
> core files identified as ELFOSABI_NONE are Linux. 

I agree that other OS's may use it or have used it in the past but I don't 
know if any of those are supported by LLDB at the moment. (If they are 
then they probably have the same problem.)
It's definitely annoying that Linux doesn't seem to use the value that 
makes sense but as it stands the case statement in ArchSpec.cpp won't 
actually hit its Linux case at the moment (which is quite confusing). I 
guess I just didn't want to bypass the trivial fix if it didn't affect 
anything else in practise.

> ObjectFileELF::RefineModuleDetailsFromNote looks for a note with 
> type NT_FILE, then looks in that for a path that starts with "/lib/
> x86_64-linux-gnu". If it finds that, it will set the core file's OS 
> to Linux. Teaching that to speak the Linux dialect you're interested
> in is probably the right way to go.

The problem with that is the Redhat cores I have to hand (from various 
test machines) have the FILE note section but the library files are in 
/usr/lib (32 bit) or  /usr/lib64 (64 bit). That looks sufficiently generic 
that identifying the OS as Linux based on those would probably have the 
same effect as using ELFOSABI_NONE. The paths LLDB currently knows about 
(and match my Ubuntu box) are /lib/i386-linux-gnu and 
/lib/x86_64-linux-gnu. Since they have "linux" in them they a much safer 
bet.

I also have some other cores taken from Ubuntu running in a containerised 
environment where the library path in the core is actually the full path 
from outside the container, so it only ends in /lib/x86_64-linux-gnu, the 
full path is /packages/rootfs_cflinuxfs2/[very long UID 
value]/rootfs/lib/x86_64-linux-gnu/[library].so. (This may be a container 
problem though, I'm not sure if using core dumps to discover this path is 
actually a bug.)

Howard Hellyer
IBM Runtime Technologies, IBM Systems





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160823/527307ec/attachment.html>