8 Commits

Author SHA1 Message Date
David Spickett
40ee8abee7 [llvm-objdump] Make arm64ec.yaml warning check less strict to account for Windows
When 7a28b0b60e81a0472bfc6af992e824ef01cc08b8 added this it wanted
"llvm-objdump: warning: <...>". On our Windows on Arm bot you get:
c:\users\tcwg\llvm-worker\clang-arm64-windows-msvc\stage1\bin\llvm-objdump.exe: warning:

Seems unlikely the warning would come from anywhere else and if
it does, this test isn't the one to be catching that. So I've
shortened the checks to start at "warning: ".
2023-08-15 16:46:04 +00:00
Jacek Caban
7a28b0b60e [llvm-objdump] Support CHPE code ranges in disassembler.
Reviewed By: jhenderson, MaskRay
Differential Revision: https://reviews.llvm.org/D149095
2023-08-15 00:06:51 +02:00
Jacek Caban
23821568f6 [llvm-objdump] [NFC] Add missing REQUIRES to arm64ec.yaml.
Differential Revision: https://reviews.llvm.org/D149091
2023-07-24 20:56:54 +02:00
Jacek Caban
c33397f712 Recognize ARM64EC binaries in COFFObjectFile::getMachine.
ARM64EC/ARM64X binaries use ARM64 or AMD64 machine types, but provide
additional CHPE metadata that may be used to distinguish them from
pure ARM64/AMD64 binaries.

Reviewed By: jhenderson, MaskRay, mstorsjo
Differential Revision: https://reviews.llvm.org/D149091
2023-07-24 20:41:20 +02:00
Pengxuan Zheng
064db24311 [Object][COFF] Fix section name parsing error when the name field is not null-padded
Some object files produced by Mirosoft tools contain sections whose name field
is not fully null-padded at the end. Microsoft's dumpbin is able to print the
section name correctly, but this causes parsing errors with LLVM tools.

So far, this issue only seems to happen when the section name is longer than 8
bytes. In this case, the section name field contains a slash (/) followed by the
offset into the string table, but the name field is not fully null-padded at the
end.

Reviewed By: mstorsjo

Differential Revision: https://reviews.llvm.org/D127369
2022-06-09 12:58:28 -07:00
Fangrui Song
5f1e509579 [llvm-objdump] -p: Dump PE header for PE/COFF
For a trivial DLL built with `clang --target=x86_64-windows -O2 -c a.c; lld-link -subsystem:console -dll a.o -out:a.dll`,
`objdump -p` vs `llvm-objdump -p`:

```
-a.dll:     file format pei-x86-64
-
+a.dll: file format coff-x86-64
 Characteristics 0x2022
        executable
        large address aware
@@ -57,4 +56,4 @@
 Entry d 0000000000000000 00000000 Delay Import Directory
 Entry e 0000000000000000 00000000 CLR Runtime Header
 Entry f 0000000000000000 00000000 Reserved
-
+Export Table:
```

For a Linux image (`vmlinuz-5.10.76-gentoo-r1`) built with `CONFIG_EFI_STUB=y`

```
-vmlinuz-5.10.76-gentoo-r1:     file format pei-x86-64
-
-Characteristics 0x20e
+vmlinuz-5.10.76-gentoo-r1:     file format coff-x86-64
+Characteristics 0x206
        executable
        line numbers stripped
-       symbols stripped
        debugging information removed

 Time/Date              Wed Dec 31 16:00:00 1969
@@ -55,10 +53,4 @@
 Entry d 0000000000000000 00000000 Delay Import Directory
 Entry e 0000000000000000 00000000 CLR Runtime Header
 Entry f 0000000000000000 00000000 Reserved
-
-
-PE File Base Relocations (interpreted .reloc section contents)
-
-Virtual Address: 000037ca Chunk size 10 (0xa) Number of fixups 1
-       reloc    0 offset    0 [37ca] ABSOLUTE
-
+Export Table:
```

`symbols stripped` looks like a GNU objdump problem.

Reviewed By: jhenderson, alexander-shaposhnikov

Differential Revision: https://reviews.llvm.org/D113356
2021-11-09 10:08:41 -08:00
Fangrui Song
6ed18eaa77 [llvm-objdump][test] Change llvm-objdump tests to use double dash options 2020-03-15 16:01:26 -07:00
Fangrui Song
6d026c89dc [llvm-objdump][test] Move binary format specific tests under COFF/ ELF/ MachO/ XCOFF/ wasm/
Reviewed By: grimar

Differential Revision: https://reviews.llvm.org/D75798
2020-03-09 08:04:48 -07:00