Add e_flags information to ELF core files

[sson]

Summary

LLDB (3.8) expects the e_flags field in the ELF header to contain instruction set/CPU information for at least the MIPS CPU:

LLDB ELF header parser

MIPS ELF header definitions

Otherwise, LLDB gives the following error when trying to debug a mips corefile:

% lldb-3.9.0 mips64.a.out -c mips64.a.out.core
error: Unable to find process plug-in for core file 'mips64.a.out.core'

This change adds the correct e_flags field information for the CPU type in core files generated by the kernel for MIPS and adds stubs to the other arch's to do the same.

Test Plan

% lldb-3.9.0 mips64.a.out -c mips64.a.out.core

[imp]

I don't like this interface. The CPU specific eflags aren't a property of the CPU, but rather are a property of how the binary was compiled. These should be in the header for the binary being executed, which is completely ignored. On arm, there's at least two flavors we support executing today. On mips we support 3 different binary ABIs. And we wish to support more flavors of those ABIs (soft-float, hard-float, cheri) and you can't know based on the kernel which one of these you are running.

sys/arm/arm/elf_machdep.c

301

This almost certainly isn't right.
At the very least we should encode EABI 5.

It would be desirable to also encode the float ABI (hard or soft), but to do that, you need to use the ehdr->eflags field from the original binary, and I don't see a good way to do that given this interface.

sys/mips/mips/elf_machdep.c

360–385

This is almost certainly wrong. It's about the binary that's being executed, not what the kernel is compiled for.

[imp]

Also, the LLVM parser is wrong.

case llvm::ELF::EF_MIPS_ARCH_3:
case llvm::ELF::EF_MIPS_ARCH_4:
case llvm::ELF::EF_MIPS_ARCH_5:
case llvm::ELF::EF_MIPS_ARCH_64:
    return (endian == ELFDATA2LSB) ? ArchSpec::eMIPSSubType_mips64el : ArchSpec::eMIPSSubType_mips64;

This is incorrect. These arch (at least the first two) are both 32-bit and 64-bit. You know what arch you are executing based on the e_ident[EI_CLASS} telling you 32 vs 64 bit.

32-bit mips FreeBSD binaries are MIPS-3. And that's correct. And LLVM doesn't grok that. So the LLVM parser also needs work.

[sson]

In D5171#110106, @imp wrote:

I don't like this interface. The CPU specific eflags aren't a property of the CPU, but rather are a property of how the binary was compiled. These should be in the header for the binary being executed, which is completely ignored. On arm, there's at least two flavors we support executing today. On mips we support 3 different binary ABIs. And we wish to support more flavors of those ABIs (soft-float, hard-float, cheri) and you can't know based on the kernel which one of these you are running.

Good point. The eflags from the executable should be used. Of course, LLDB should have that information but it is possible to load a core file without specifying a target executable. (I am not sure how that is useful.)

[sson]

In D5171#110109, @imp wrote:

Also, the LLVM parser is wrong.

case llvm::ELF::EF_MIPS_ARCH_3:
case llvm::ELF::EF_MIPS_ARCH_4:
case llvm::ELF::EF_MIPS_ARCH_5:
case llvm::ELF::EF_MIPS_ARCH_64:
    return (endian == ELFDATA2LSB) ? ArchSpec::eMIPSSubType_mips64el : ArchSpec::eMIPSSubType_mips64;

This is incorrect. These arch (at least the first two) are both 32-bit and 64-bit. You know what arch you are executing based on the e_ident[EI_CLASS} telling you 32 vs 64 bit.

32-bit mips FreeBSD binaries are MIPS-3. And that's correct. And LLVM doesn't grok that. So the LLVM parser also needs work.

Yes, it looks like there has been some confusion with these bits: https://github.com/llvm-mirror/lldb/commit/de2b360b0d516d8cdaeb0147ad3687ce65c6d370

[sson]

I will fix this in LLDB. Thanks Warner!