We do not check the GNU-style output when -all is given.
This patch does that.
Details
Diff Detail
Event Timeline
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. |
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. | |
64 | Yes.
| |
76–77 |
Yes, we need it to get the DT_HASH content: | |
87–91 | No. We need to have something valid here, otherwise any | |
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 |
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. |
- 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. 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? | |
101 | Yep, probably SHT_NOTE will be the next. |
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). |
test/tools/llvm-readobj/all.test | ||
---|---|---|
87–91 |
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! |
test/tools/llvm-readobj/all.test | ||
---|---|---|
87–91 | I've build GNU readelf (GNU Binutils) 2.33.50.20191008 today and it still shows It seems to be a known one year old bug: And one of interesting comments is: 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? |
test/tools/llvm-readobj/all.test | ||
---|---|---|
87–91 | Sounds good! |
These two appear to be missing from the LLVM list above?