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

[Howard Hellyer via lldb-dev]

I've been trying to understand why some Linux core files fail to load in 
lldb.

The problem seems to be that in the ELF header Linux uses the 
ELFOSABI_NONE (0x0) value rather than ELFOSABIT_LINUX (0x3).If I either 
change the e_ident[EI_OSABI] byte to 0x3 in the header or the code in 
ArchSpec.cpp to treat ELFOSABI_NONE as Linux then LLDB will open these 
core files perfectly. The Linux core dumps that are being opened 
successfully seem to be doing so because lldb is using extra optional 
information in the notes section. Either because it contains notes “owned” 
by Linux or because of the file names contained in the FILE note type. A 
lot of core dumps (it appears to be those created by the kernel following 
a crash rather than gcore) don’t contain the “LINUX” notes and the file 
paths in the FILE note can vary a lot by Linux distribution. (For example 
Ubuntu cores work but Redhat cores I've tried don't as the libraries are 
in different locations.)

Linux doesn't seem to use the ELFOSABIT_LINUX value (0x3) but sticks to 
the ELFOSABI_NONE (0x0) value. This apppears to be true for both 
executables and core dumps, LLVM was changed to follow this convention 
(see: 
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150921/301607.html 
) but lldb still looks for ELFOSABI_LINUX in ELF headers even though 
executables and core files seem to contain ELFOSABI_NONE in practise. If I 
compile code with clang the resulting executable uses ELFOSABI_NONE in the 
e_ident[EI_OSABI] byte. (If I change the byte manually Linux doesn't 
appear to care. I think it's probably ignoring the byte.)

I'd like to submit a patch to change lldb to treat ELF files with 
ELFOSABI_NONE set as Linux as a) it would allow lldb to open Linux cores 
reliably and b) it would match how clang treats e_ident[EI_OSABI]. The 
code to detect whether lldb is opening a Linux core has changed a lot 
recently and I don't know the history or if any other ELF platforms leave 
this byte set to 0x0 in which case this would be confusing, though as this 
value is currently unused it seems safe.

Does anyone know of any reason not to change this? If not I'll submit a 
patch for review.

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/20160822/14b31d61/attachment.html>