[Lldb-commits] [PATCH] D62213: [ABI] Implement Windows ABI for x86_64
Pavel Labath via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Tue Jun 18 23:37:40 PDT 2019
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
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
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
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 648 (bytes into file)
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
[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.
CHANGES SINCE LAST ACTION
More information about the lldb-commits