> 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
