labath added a comment.
In D62213#1549190 <https://reviews.llvm.org/D62213#1549190>, @kusmour wrote:
> > Maybe we should make the SysV abi plugin match unknown oss too...
>
> I'm not sure this is the right thing to do, but this should fix the problem.
It would at least preserve status quo. Not much, but it is something...
>> The only format where we have trouble determining the OS is ELF, and it's a
>> pretty good bet that any elf file will be using the "SysV" ABI...
>
> Can you provide more information about this? It sounds like a bug
Well.. you could consider it a bug, but it's quite hard to say where that bug
is (it's definitely not a bug in lldb or llvm-mc). A sad fact of life is that
the ELF files don't usually carry enough information to properly identify the
os/environment they were intended to run on. If you run `readelf -e` on the
file generated in the test, you'll get something like
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 648 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 64 (bytes)
Number of section headers: 9
Section header string table index: 1
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .strtab STRTAB 0000000000000000 00000238
000000000000004e 0000000000000000 0 0 1
[ 2] .text PROGBITS 0000000000000000 00000040
0000000000000003 0000000000000000 AX 0 0 4
[ 3] .debug_str PROGBITS 0000000000000000 00000043
000000000000001b 0000000000000001 MS 0 0 1
[ 4] .debug_loc PROGBITS 0000000000000000 0000005e
0000000000000036 0000000000000000 0 0 1
[ 5] .debug_abbrev PROGBITS 0000000000000000 00000094
000000000000002d 0000000000000000 0 0 1
[ 6] .debug_info PROGBITS 0000000000000000 000000c1
000000000000003d 0000000000000000 0 0 1
[ 7] .rela.debug_info RELA 0000000000000000 00000190
00000000000000a8 0000000000000018 8 6 8
[ 8] .symtab SYMTAB 0000000000000000 00000100
0000000000000090 0000000000000018 1 6 8
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
l (large), p (processor specific)
There are no program headers in this file.
The elf header has this OS/ABI field which could be used to specify linux, but
here it's just set to the generic "none" value (which gets printed as "unix
sysv"). There is a value for ELFOSABI_LINUX/ELFOSABI_GNU, which could be used
to say "linux", but it seems nobody uses it (I'm not sure what's the background
there). I guess that usually wasn't a problem, because tools would just assume
they are dealing with binaries for the host platform, but lldb has a strong
desire to know what platform is a binary intended for without assuming anything
about the environment it's being run it. That desire is understandable, but it
kind of collides with reality. Over time, lldb has developed a bunch of
heuristics to determine the right OS for a file, but these are just heuristics,
and they fail on extremely simple files like the ones used in this test,
because they have nothing to go on.
Repository:
rLLDB LLDB
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D62213/new/
https://reviews.llvm.org/D62213
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
