[lldb-dev] Linux ELF header e_ident[EI_OSABI] value
Ted Woodward via lldb-dev
lldb-dev at lists.llvm.org
Mon Aug 22 13:03:02 PDT 2016
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.
Whe lldb loads a core file with a target binary, it will merge the 2 triples. If it can't identify the OS from the core file, it will use the OS from the target file. For example, I just loaded a Hexagon Linux core file, which lldb didn't identify as Linux, and a Hexagon Linux target, which lldb did identify as Linux. The final triple is correct - hexagon-*-linux:
(lldb) file u:\hexagon-linux\crash -c u:\hexagon-linux\core
Core file 'u:\hexagon-linux\core' (hexagon) was loaded.
(lldb) tar list
* target #0: u:\hexagon-linux\crash ( arch=hexagon-*-linux, platform=remote-linux, pid=13818, state=stopped )
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.
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
From: lldb-dev [mailto:lldb-dev-bounces at lists.llvm.org] On Behalf Of Greg Clayton via lldb-dev
Sent: Monday, August 22, 2016 11:00 AM
To: Howard Hellyer <HHELLYER at uk.ibm.com>
Cc: lldb-dev at lists.llvm.org
Subject: Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value
> 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.
lldb-dev mailing list
lldb-dev at lists.llvm.org
More information about the lldb-dev