[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

  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.




More information about the lldb-commits mailing list