This is an archive of the discontinued LLVM Phabricator instance.

[llvm-readobj/llvm-readelf] - Add checks for GNU-style to "all.test" test case.
ClosedPublic

Authored by grimar on Oct 4 2019, 6:19 AM.

Diff Detail

Event Timeline

grimar created this revision.Oct 4 2019, 6:19 AM
grimar updated this revision to Diff 223202.Oct 4 2019, 6:22 AM
  • Removed 2 missed unused tags from the YAML description.
jhenderson added inline comments.Oct 4 2019, 8:36 AM
test/tools/llvm-readobj/all.test
27–28

These two appear to be missing from the LLVM list above?

33–34

These two are also missing from the LLVM list.

50

I take it the version stuff is needed to make GNU mode print anything?

64

Do we need group information to print a header?

76–77

Can we just get away with the DT_NULL tag, or is DT_HASH required for the hash histogram behaviour?

87–91

Same comments as earlier. Can these be empty?

101

This could probably just be an arbitrary note, and much simpler.

grimar marked 14 inline comments as done.Oct 7 2019, 4:15 AM
grimar added inline comments.
test/tools/llvm-readobj/all.test
27–28

Yes. LLVM output seems to be inconsistent, incomplete and ugly sometimes. I'd review and refine it separatelly.

33–34

The same.

50

Yep, GNU style prints nothing if there is no version section.
See: https://github.com/llvm-mirror/llvm/blob/master/tools/llvm-readobj/ELFDumper.cpp#L3785

64
76–77

is DT_HASH required for the hash histogram behaviour?

Yes, we need it to get the DT_HASH content:
https://github.com/llvm-mirror/llvm/blob/master/tools/llvm-readobj/ELFDumper.cpp#L1712

87–91

No. We need to have something valid here, otherwise any
error triggered will fail the dumping.
(e.g. https://github.com/llvm-mirror/llvm/blob/master/tools/llvm-readobj/DwarfCFIEHPrinter.h#L127).

101

Probably. But it is already short enough and I do not want to spend time on optimising it until we have a way to describe
it with YAML. Having a raw content is anyways not optimal. What do you think?

jhenderson added inline comments.Oct 7 2019, 4:46 AM
test/tools/llvm-readobj/all.test
64

I see. Could you just check the "There are no section groups in the file" message instead? (https://github.com/llvm-mirror/llvm/blob/master/tools/llvm-readobj/ELFDumper.cpp#L2911)

I think that would be sufficient for this test case.

87–91

You don't actually need the .eh_frame_hdr at all, looking at the code, I think, just the .eh_frame section. That said, this appears to be different from GNU readelf.

For reference, GNU readelf prints "There are no unwind sections in this file" if there are no .eh_frame_hdr sections even if there is a .eh_frame section (not looked to see what happens if there is a PT_GNU_EH_FRAME program header).

101

Time to implement SHT_NOTE sections in yaml2obj :)

But happy for that to be later.

grimar updated this revision to Diff 223578.Oct 7 2019, 7:04 AM
grimar marked 14 inline comments as done.
  • Addressed review comments.
test/tools/llvm-readobj/all.test
64

Done.

87–91

I am a bit confused.

Imagine we have the code and invocations below:

"1.s":

.section foo,"ax",@progbits
.cfi_startproc
 nop
.cfi_endproc
as 1.s -o 1.o
ld.bfd 1.o -o with_hdr --eh-frame-hdr
ld.bfd 1.o -o wo_hdr

For both of them I do not see neither .eh_frame_hdr nor .eh_frame section dumped with -a.
I see ".eh_frame" dumped when I add -wf though (but still no .eh_frame_hdr).
e.g.:

umb@ubuntu:~/tests/81$ readelf -v
GNU readelf (GNU Binutils for Ubuntu) 2.31.1
Copyright (C) 2018 Free Software Foundation, Inc.

umb@ubuntu:~/tests/81$ readelf -a with_hdr
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:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x401000
  Start of program headers:          64 (bytes into file)
  Start of section headers:          8584 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         3
  Size of section headers:           64 (bytes)
  Number of section headers:         7
  Section header string table index: 6

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] foo               PROGBITS         0000000000401000  00001000
       0000000000000001  0000000000000000  AX       0     0     1
  [ 2] .eh_frame_hdr     PROGBITS         0000000000402000  00002000
       0000000000000014  0000000000000000   A       0     0     4
  [ 3] .eh_frame         PROGBITS         0000000000402018  00002018
       000000000000002c  0000000000000000   A       0     0     8
  [ 4] .symtab           SYMTAB           0000000000000000  00002048
       00000000000000d8  0000000000000018           5     5     8
  [ 5] .strtab           STRTAB           0000000000000000  00002120
       000000000000002c  0000000000000000           0     0     1
  [ 6] .shstrtab         STRTAB           0000000000000000  0000214c
       0000000000000037  0000000000000000           0     0     1
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 section groups in this file.

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000001000 0x0000000000401000 0x0000000000401000
                 0x0000000000000001 0x0000000000000001  R E    0x1000
  LOAD           0x0000000000002000 0x0000000000402000 0x0000000000402000
                 0x0000000000000044 0x0000000000000044  R      0x1000
  GNU_EH_FRAME   0x0000000000002000 0x0000000000402000 0x0000000000402000
                 0x0000000000000014 0x0000000000000014  R      0x4

 Section to Segment mapping:
  Segment Sections...
   00     foo 
   01     .eh_frame_hdr .eh_frame 
   02     .eh_frame_hdr 

There is no dynamic section in this file.

There are no relocations in this file.

The decoding of unwind sections for machine type Advanced Micro Devices X86-64 is not currently supported.

Symbol table '.symtab' contains 9 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000401000     0 SECTION LOCAL  DEFAULT    1 
     2: 0000000000402000     0 SECTION LOCAL  DEFAULT    2 
     3: 0000000000402018     0 SECTION LOCAL  DEFAULT    3 
     4: 0000000000402000     0 NOTYPE  LOCAL  DEFAULT    2 __GNU_EH_FRAME_HDR
     5: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND _start
     6: 0000000000404000     0 NOTYPE  GLOBAL DEFAULT    3 __bss_start
     7: 0000000000404000     0 NOTYPE  GLOBAL DEFAULT    3 _edata
     8: 0000000000404000     0 NOTYPE  GLOBAL DEFAULT    3 _end

No version information found in this file.

umb@ubuntu:~/tests/81$ readelf -a with_hdr -wf
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:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x401000
  Start of program headers:          64 (bytes into file)
  Start of section headers:          8584 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         3
  Size of section headers:           64 (bytes)
  Number of section headers:         7
  Section header string table index: 6

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] foo               PROGBITS         0000000000401000  00001000
       0000000000000001  0000000000000000  AX       0     0     1
  [ 2] .eh_frame_hdr     PROGBITS         0000000000402000  00002000
       0000000000000014  0000000000000000   A       0     0     4
  [ 3] .eh_frame         PROGBITS         0000000000402018  00002018
       000000000000002c  0000000000000000   A       0     0     8
  [ 4] .symtab           SYMTAB           0000000000000000  00002048
       00000000000000d8  0000000000000018           5     5     8
  [ 5] .strtab           STRTAB           0000000000000000  00002120
       000000000000002c  0000000000000000           0     0     1
  [ 6] .shstrtab         STRTAB           0000000000000000  0000214c
       0000000000000037  0000000000000000           0     0     1
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 section groups in this file.

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000001000 0x0000000000401000 0x0000000000401000
                 0x0000000000000001 0x0000000000000001  R E    0x1000
  LOAD           0x0000000000002000 0x0000000000402000 0x0000000000402000
                 0x0000000000000044 0x0000000000000044  R      0x1000
  GNU_EH_FRAME   0x0000000000002000 0x0000000000402000 0x0000000000402000
                 0x0000000000000014 0x0000000000000014  R      0x4

 Section to Segment mapping:
  Segment Sections...
   00     foo 
   01     .eh_frame_hdr .eh_frame 
   02     .eh_frame_hdr 

There is no dynamic section in this file.

There are no relocations in this file.

The decoding of unwind sections for machine type Advanced Micro Devices X86-64 is not currently supported.

Symbol table '.symtab' contains 9 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000401000     0 SECTION LOCAL  DEFAULT    1 
     2: 0000000000402000     0 SECTION LOCAL  DEFAULT    2 
     3: 0000000000402018     0 SECTION LOCAL  DEFAULT    3 
     4: 0000000000402000     0 NOTYPE  LOCAL  DEFAULT    2 __GNU_EH_FRAME_HDR
     5: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND _start
     6: 0000000000404000     0 NOTYPE  GLOBAL DEFAULT    3 __bss_start
     7: 0000000000404000     0 NOTYPE  GLOBAL DEFAULT    3 _edata
     8: 0000000000404000     0 NOTYPE  GLOBAL DEFAULT    3 _end

No version information found in this file.
Contents of the .eh_frame section:


00000000 0000000000000014 00000000 CIE
  Version:               1
  Augmentation:          "zR"
  Code alignment factor: 1
  Data alignment factor: -8
  Return address column: 16
  Augmentation data:     1b
  DW_CFA_def_cfa: r7 (rsp) ofs 8
  DW_CFA_offset: r16 (rip) at cfa-8
  DW_CFA_nop
  DW_CFA_nop

00000018 0000000000000010 0000001c FDE cie=00000000 pc=0000000000401000..0000000000401001
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop

I also see ".eh_frame" dumped when there is no ".eh_frame_hdr":

umb@ubuntu:~/tests/81$ readelf -a wo_hdr -wf
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:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x401000
  Start of program headers:          64 (bytes into file)
  Start of section headers:          8480 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         2
  Size of section headers:           64 (bytes)
  Number of section headers:         6
  Section header string table index: 5

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] foo               PROGBITS         0000000000401000  00001000
       0000000000000001  0000000000000000  AX       0     0     1
  [ 2] .eh_frame         PROGBITS         0000000000402000  00002000
       000000000000002c  0000000000000000   A       0     0     8
  [ 3] .symtab           SYMTAB           0000000000000000  00002030
       00000000000000a8  0000000000000018           4     3     8
  [ 4] .strtab           STRTAB           0000000000000000  000020d8
       0000000000000019  0000000000000000           0     0     1
  [ 5] .shstrtab         STRTAB           0000000000000000  000020f1
       0000000000000029  0000000000000000           0     0     1
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 section groups in this file.

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000001000 0x0000000000401000 0x0000000000401000
                 0x0000000000000001 0x0000000000000001  R E    0x1000
  LOAD           0x0000000000002000 0x0000000000402000 0x0000000000402000
                 0x000000000000002c 0x000000000000002c  R      0x1000

 Section to Segment mapping:
  Segment Sections...
   00     foo 
   01     .eh_frame 

There is no dynamic section in this file.

There are no relocations in this file.

The decoding of unwind sections for machine type Advanced Micro Devices X86-64 is not currently supported.

Symbol table '.symtab' contains 7 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000401000     0 SECTION LOCAL  DEFAULT    1 
     2: 0000000000402000     0 SECTION LOCAL  DEFAULT    2 
     3: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND _start
     4: 0000000000404000     0 NOTYPE  GLOBAL DEFAULT    2 __bss_start
     5: 0000000000404000     0 NOTYPE  GLOBAL DEFAULT    2 _edata
     6: 0000000000404000     0 NOTYPE  GLOBAL DEFAULT    2 _end

No version information found in this file.
Contents of the .eh_frame section:


00000000 0000000000000014 00000000 CIE
  Version:               1
  Augmentation:          "zR"
  Code alignment factor: 1
  Data alignment factor: -8
  Return address column: 16
  Augmentation data:     1b
  DW_CFA_def_cfa: r7 (rsp) ofs 8
  DW_CFA_offset: r16 (rip) at cfa-8
  DW_CFA_nop
  DW_CFA_nop

00000018 0000000000000010 0000001c FDE cie=00000000 pc=0000000000401000..0000000000401001
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop

}

Since we have such differences in the behavior, should we just test the current behavior atm?
I.e. before this diff I tested "EH_FRAME Header [", now I also added a check for ".eh_frame section at offset...".
Both of them are dumped at the top level currently. Seems reasonable to test the fact we do that (with just -all)
and the order, probably?
(I am ok to change it in any way actually, but just wanted to clarify this before doing anything with it.)

101

Yep, probably SHT_NOTE will be the next.

jhenderson accepted this revision.Oct 7 2019, 7:20 AM

LGTM.

test/tools/llvm-readobj/all.test
87–91

I'm confused too. Your output above even appears to be conflicted. Note that it mentions "The decoding of unwind sections for machine type Advanced Micro Devices X86-64 is not currently supported."

Anyway, probably best to file a bug to record the issue and then do as you're doing here (i.e. test the current behaviour).

This revision is now accepted and ready to land.Oct 7 2019, 7:20 AM
grimar marked an inline comment as done.Oct 7 2019, 7:28 AM
grimar added inline comments.
test/tools/llvm-readobj/all.test
87–91

Note that it mentions "The decoding of unwind sections for machine type Advanced Micro Devices X86-64 is not currently supported."

Yes, that looks strange. I'll build the latest binutils from sources tomorrow and check what it do, then probably file a bug or prepare a patch. Thanks for review!

grimar marked an inline comment as done.Oct 8 2019, 1:26 AM
grimar added inline comments.
test/tools/llvm-readobj/all.test
87–91

I've build GNU readelf (GNU Binutils) 2.33.50.20191008 today and it still shows
"The decoding of unwind sections for machine type Advanced Micro Devices X86-64 is not currently supported."
for me when I request "-a" or "-u" (--unwind Display the unwind info (if present))

It seems to be a known one year old bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1626614

And one of interesting comments is:
"A workaround is readelf -wF or -wf however, it is unclear to me why -u isn't wired up to do the same thing as -wf. Is that something worth considering?"

I am going to commit this patch and do nothing else for it atm (i.e. will not report any bugs for llvm-readelf until situation with GNU be fixed, since the current our behavior looks valid and I probably see no issues). How does it sound for you?

jhenderson added inline comments.Oct 8 2019, 1:43 AM
test/tools/llvm-readobj/all.test
87–91

Sounds good!

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptOct 8 2019, 2:00 AM