Page MenuHomeFreeBSD

Add e_flags information to ELF core files
AbandonedPublic

Authored by sson on Feb 2 2016, 8:41 PM.

Details

Reviewers
emaste
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

Diff Detail

Repository
rS FreeBSD src repository
Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

sson updated this revision to Diff 12963.Feb 2 2016, 8:41 PM
sson retitled this revision from to Add e_flags information to ELF core files.
sson updated this object.
sson edited the test plan for this revision. (Show Details)
sson added a reviewer: emaste.
sson set the repository for this revision to rS FreeBSD src repository.
sson added a project: MIPS.
imp added a comment.Feb 3 2016, 5:21 PM

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 added a comment.Feb 3 2016, 5:29 PM

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 added a comment.Feb 3 2016, 5:33 PM
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 added a comment.Feb 3 2016, 5:42 PM
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 abandoned this revision.Feb 3 2016, 10:24 PM

I will fix this in LLDB. Thanks Warner!