[Lldb-commits] [PATCH] D62213: [ABI] Implement Windows ABI for x86_64

[Pavel Labath via Phabricator via lldb-commits]

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