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 Current targets: * 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 -----Original Message----- From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg Clayton via lldb-dev Sent: Monday, August 22, 2016 11:00 AM To: Howard Hellyer <hhell...@uk.ibm.com> Cc: lldb-dev@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@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 _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
