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

[Greg Clayton via lldb-dev]

> On Aug 22, 2016, at 6:00 AM, Howard Hellyer via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> 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. 

I would change it so that the "os" doesn't get set to anything when it detects this in the core file. When an OS is not specified, the llvm::Triple will return OSUnknown as the enumeration value for the OS _and_ the llvm::StringRef value will return an empty string. This is known in LLDB term as a "unspecified unknown". This means the triple will be "x86_64-*-<vendor>". An unspecified unknown is a wildcard. Any plugins that are trying to load a core file should watch for this and use it accordingly.

So the answer is not "treat ELF files with ELFOSABI_NONE set as Linux", but "treat ELF files with ELFOSABI_NONE set as *". Please submit a patch that implements this when you get the chance. Let me know if you have any questions.

Greg Clayton