This patch introduces a new generic target, `gfx9-4-generic`. Since it doesn’t support FP8 and XF32-related instructions, the patch includes several code reorganizations to accommodate these changes.
An error reading a bitcode file most likely indicates that the file
was created by a compiler from the future. Normally we don't try to
implement forwards compatibility for bitcode files, but when creating
an archive we can implement best-effort forwards compatibility by
treating the file as a blob and not creating symbol index entries for
it. lld and mold ignore the archive symbol index, so provided that
you use one of these linkers, LTO will work as long as lld or the
gold plugin is newer than the compiler. We only ignore errors if the
archive format is one that is supported by a linker that is known to
ignore the index, otherwise there's no chance of this working so we
may as well error out. We print a warning on read failure so that
users of linkers that rely on the symbol index can diagnose the issue.
This is the same behavior as GNU ar when the linker plugin returns
an error when reading the input file. If the bitcode file is actually
malformed, it will be diagnosed at link time.
Reviewers: MaskRay, dwblaikie, jh7370
Reviewed By: MaskRay, dwblaikie, jh7370
Pull Request: https://github.com/llvm/llvm-project/pull/96848
`MachORebaseEntry::moveNext()` and `MachOBindEntry::moveNext()` assume
that the rebase/bind table ends with `{REBASE|BIND}_OPCODE_DONE` or an
actual rebase/bind. However a valid rebase/bind table might also end
with other effectively no-op opcodes, which caused the parser to move
past the end and go into the next table, resulting in corrupted entries
or infinite loops.
`Count` and `Skip` should use `uint64_t` as they are encoded/decoded
using 64-bit ULEB128.
In `*_OPCODE_DO_*_ULEB_TIMES_SKIPPING_ULEB`, `Skip` could be encoded as
a two's complement for moving `SegmentOffset` backwards. Having a 32-bit
`Skip` truncates the encoded value and leads to a malformed
`AdvanceAmount`
and invalid `SegmentOffset` that extends past valid sections.
These test cases are testing features not available when either
targeting the s390x-ibm-zos target or use tools/features not available
on the z/OS operating system. In a couple cases the lit test had a
number of subtests with one or two that aren't supported on z/OS. Rather
than mark the entire test as unsupported I split out the unsupported
tests into a separate test case.
These generic targets include multiple GPUs and will, in the future,
provide a way to build once and run on multiple GPU, at the cost of less
optimization opportunities.
Note that this is just doing the compiler side of things, device libs an
runtimes/loader/etc. don't know about these targets yet, so none of them
actually work in practice right now. This is just the initial commit to
make LLVM aware of them.
This contains the documentation changes for both this change and #76954
as well.
nm already prints sizes for data symbols. Do that for function symbols
too, and update objdump to also print size information.
Implements item 3 from https://github.com/llvm/llvm-project/issues/76107
Currently symbol info is generated from a linking section or from export
names. This PR generates symbols in a WasmObjectFile from the name
section as well, which allows tools like objdump and nm to show useful
information for more linked binaries. There are some limitations:
most notably that we don't assume any particular ABI, so we don't get
detailed information about data symbols if the segments are merged
(which is the default).
Covers most of the desired functionality from #76107
This change allows a WasmObjectFile to be created from a wasm file even
if it uses typed funcrefs and GC types. It does not significantly change how
lib/Object models its various internal types (e.g. WasmSignature,
WasmElemSegment), so LLVM does not really "support" or understand such
files, but it is sufficient to parse the type, global and element sections, discarding
types that are not understood. This is useful for low-level binary tools such as
nm and objcopy, which use only limited aspects of the binary (such as function
definitions) or deal with sections as opaque blobs.
This is done by allowing `WasmValType` to have a value of `OTHERREF`
(representing any unmodeled reference type), and adding a field to
`WasmSignature` indicating it's a placeholder for an unmodeled reference
type (since there is a 1:1 correspondence between WasmSignature objects
and types in the type section).
Then the object file parsers for the type and element sections are expanded
to parse encoded reference types and discard any unmodeled fields.
Currently, obj2yaml doesn't emit the offset of program headers, leaving
it to yaml2obj to calculate offsets based on `FirstSec` and `LastSec`.
This causes an obj2yaml->yaml2obj round trip to often produce an ELF
file that is not equivalent to the original, especially since it seems
common to have program headers at offset 0 whose first section starts at
a higher address. Besides being non-equivalent, the produced ELF files
also do not seem to work propery and readelf complains about them.
Taking a simple hello world program in C, compiled using either GCC or
Clang, the original ELF file has the following program headers (only
showing some relevant ones):
```
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040
0x00000000000002d8 0x00000000000002d8 R 0x8
INTERP 0x0000000000000318 0x0000000000000318 0x0000000000000318
0x000000000000001c 0x000000000000001c R 0x1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000630 0x0000000000000630 R 0x1000
LOAD 0x0000000000001000 0x0000000000001000 0x0000000000001000
0x0000000000000161 0x0000000000000161 R E 0x1000
...
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.gnu.property .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt
03 .init .plt .text .fini
...
```
While this is the result of an obj2yaml->yaml2obj round trip:
```
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000000 0x0000000000000040 0x0000000000000040
0x0000000000000000 0x0000000000000000 R 0x8
readelf: Error: the PHDR segment is not covered by a LOAD segment
INTERP 0x0000000000000318 0x0000000000000318 0x0000000000000318
0x000000000000001c 0x000000000000001c R 0x1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
LOAD 0x0000000000000318 0x0000000000000000 0x0000000000000000
0x0000000000000318 0x0000000000000318 R 0x1000
LOAD 0x0000000000001000 0x0000000000001000 0x0000000000001000
0x0000000000000161 0x0000000000000161 R E 0x1000
...
Section to Segment mapping:
Segment Sections...
00
01 .interp
02
03 .init .plt .text .fini
...
```
Note that the offset of segment 2 changed from 0x0 to 0x318. This has
two effects:
- readelf complains "Error: the PHDR segment is not covered by a LOAD
segment" since PHDR was originally covered by segment 2 but not
anymore;
- Segment 2 effectively became empty according to the section to segment
mapping.
I addition to these, the output doesn't correctly execute anymore,
crashing with a "SIGSEGV (Address boundary error)".
This patch fixes the difference in program header layout after a round
trip by explicitly emitting offsets.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D145555
The issue is uncovered by #47698: for assembly files, -triple= specifies the
full target triple while -arch= merely sets the architecture part of the default
target triple, leaving a target triple which may not make sense, e.g.
riscv64-apple-darwin.
Therefore, -arch= is error-prone and not recommended for tests. The issue has
been benign as we recognize $unknown-apple-darwin as ELF instead of rejecting it
outrightly.
Due to the nature of the issue, we don't see the issue in tests using
architectures that any of Mach-O/COFF/XCOFF supports.
Summary:
if the member file is XCOFF object file and has auxiliary header, the content of the member file need to be aligned at the
MAX(maximum alignment of .text , maximum alignment of .data). The "maximum alignment of .text" and "maximum alignment of .data" are two
field of auxiliary header of XCOFF object file.
Reviewers: James Henderson, Stephen Peckham
Differential Revision: https://reviews.llvm.org/D144872
Summary:
In big archive , there is 32bit global symbol table and 64 bit global symbol table. llvm-ar only support 32bit global symbol table this moment, we need to support the 64 bit global symbol table.
https://www.ibm.com/docs/en/aix/7.2?topic=formats-ar-file-format-big
Global Symbol Tables
Immediately following the member table, the archive file contains two global symbol tables. The first global symbol table locates 32-bit file members that define global symbols; the second global symbol table does the same for 64-bit file members. If the archive has no 32-bit or 64-bit file members, the respective global symbol table is omitted. The strip command can be used to delete one or both global symbol tables from the archive. The fl_gstoff field in the fixed-length header contains the offset to the 32-bit global symbol table, and the fl_gst64off contains the offset to the 64-bit global symbol table.
Reviewers: James Henderson,Stephen Peckham
Differential Revision: https://reviews.llvm.org/D142479
This is a follow-up to b71edfaa4ec3c998aadb35255ce2f60bba2940b0
since I forgot the lit.local.cfg files in that one.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: barannikov88, kwk
Differential Revision: https://reviews.llvm.org/D150762
If the archive contains free list and contains no member file, the buffer length doesn't equal to length of the header.
Reviewed By: Esme, DiggerLin, #powerpc
Differential Revision: https://reviews.llvm.org/D138986
This includes handling of new attributes for symbols & rpath.
In the event that an older format file is compared to tbd_v5, ignore these new attributes.
Reviewed By: ributzka
Differential Revision: https://reviews.llvm.org/D144529
Introduce initial reader for TBDv5 which is in JSON. This captures all
the currently understood fields within the internal structure
`InterfaceFile`.
New fields will be followed up in future PRs.
Reviewed By: pete
Differential Revision: https://reviews.llvm.org/D144156
This reverts commit b861b1225380175a5a724e2a677754f5f74e5b0d.
This reverts commit 4be17641b05df1e63fa8e069af92676f1246eb83.
This patch wont build on some compilers on buildbot.
[TextAPI] Implement TBDv5 Reader
Introduce initial reader for TBDv5 which is in JSON. This captures all
the currently understood fields within the internal structure
`InterfaceFile`.
New fields & follow up tests will be followed up in future PRs.
Reviewed By: pete
Differential Revision: https://reviews.llvm.org/D144156
This reverts commit 7f0003c19c3a47f484ea9cc929728808b27ace32.
Reason: This broke the ASan buildbot, see the comments in
https://reviews.llvm.org/D138986 for more information.
If the archive contains free list and contains no member file, the buffer length doesn't equal to length of the header.
Reviewed By: Esme, DiggerLin, #powerpc
Differential Revision: https://reviews.llvm.org/D138986
Add file with Xtensa ELF relocations. Add Xtensa support to ELF.h,
ELFObject.h and ELFYAML.cpp. Add simple test of Xtensa ELF representation in YAML.
Differential Revision: https://reviews.llvm.org/D64827
This reverts commit b26fe2a3e520a520e785dc6b4e5758b7fde6af9d.
Reason: Broke the ASan build bots. See more info in the original
phabricator review: https://reviews.llvm.org/D138986
If the archive contains free list and contains no member file, the buffer length doesn't equal to length of the header.
Reviewed By: Esme, DiggerLin, #powerpc
Differential Revision: https://reviews.llvm.org/D138986
The archive is generated via
```
touch foo.c
ar crus libfoo.a foo.c
ar d libfoo.a foo.c
```
Thus it contains free list.
Differential Revision: https://reviews.llvm.org/D138985
This prepares for an upcoming change to make --print-imm-hex the default
behavior of llvm-objdump. These tests were updated in a semi-automatic
fashion.
See D136972 for details.
I ran into an lld-link error due to a symbol named ".idata$4" coming from some
static library:
.idata$4 should not refer to special section 0.
Here is the symbol table entry for .idata$4:
Symbol {
Name: .idata$4
Value: 3221225536
Section: IMAGE_SYM_UNDEFINED (0)
BaseType: Null (0x0)
ComplexType: Null (0x0)
StorageClass: Section (0x68)
AuxSymbolCount: 0
}
The symbol .idata$4 is a section symbol (IMAGE_SYM_CLASS_SECTION) and LLD
currently handles it as a regular defined symbol since isCommon() returns false
for this symbol. This results in the error ".idata$4 should not refer to special
section 0" because lld-link asserts that regular defined symbols should not
refer to section 0.
Should this symbol be handled as a common symbol instead? LLVM currently only
allows external symbols (IMAGE_SYM_CLASS_EXTERNAL) to be common
symbols. However, the PE/COFF spec (see section "Section Number Values") does
not seem to mention this restriction. Any thoughts?
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D133627
Print out the archive member that failed, to make debugging easier.
Before:
error: failed to build archive: Not an int attribute (Producer: 'LLVM15.0.1git' Reader: 'LLVM 14.0.5-rust-dev')
After:
error: failed to build archive: 'fake_bt_keystore.o': Not an int attribute (Producer: 'LLVM15.0.1git' Reader: 'LLVM 14.0.5-rust-dev')
Differential Revision: https://reviews.llvm.org/D133607
It doesn't have a section header string table so add a vector to have
the strings and create name based on the program header type and the
index.
Differential Revision: https://reviews.llvm.org/D131290
llvm-objdump takes foo-bar style flags, while llvm-otool takes foo_bar style
flags. dyld_info was the only exception to that.
Add a -dyld_info flag to llvm-otool instead.
(Both in llvm-objdump and llvm-otool, the flag doesn't really do anything
yet.)
Differential Revision: https://reviews.llvm.org/D131897
The linux perf tools use /proc/kcore for disassembly kernel functions.
Actually it copies the relevant parts to a temp file and then pass it to
objdump. But it doesn't have section headers so llvm-objdump cannot
handle it.
Let's create fake section headers for the program headers. It'd have a
single section for each segment to cover the entire range. And for this
purpose we can consider only executable code segments.
With this change, I can see the following command shows proper outputs.
perf annotate --stdio --objdump=/path/to/llvm-objdump
Differential Revision: https://reviews.llvm.org/D128705
ET_EXEC and ET_DYN files may contain non-SHF_ALLOC relocation sections
(e.g. ld --emit-relocs). Match GNU objdump by dumping them.
* Remove Object/dynamic-reloc.test. Replace it with a -r RUN line in dynamic-relocs.test
* Update relocations-in-nonreloc.test to set sh_link/sh_info. GNU
objdump seems to ignore a SHT_REL/SHT_RELA section not linking to SHT_SYMTAB.
The test did not test what it intended to test.
Fix https://github.com/llvm/llvm-project/issues/41246
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D128959
The exports trie parser ordinal validation check doesn't consider the case where
the ordinal can be zero or negative for certain special values that are defined
in BindSpecialDylib. Update the validation to account for that fact and add a
test case.
This fixes rdar://94844233.
Differential Revision: https://reviews.llvm.org/D127806
Before bb94611d6545c2c5271f5bb01de1aa4228a37250, we didn't check
that the sections in the COFF executable actually contained enough
raw data, when looking up what section contains tables pointed to
by the data directories.
That commit added checking, to avoid setting a pointer that points
out of bounds - by rejecting such executables.
It turns out that some binaries (e.g.g a "helper.exe" provided by
NSIS) contains a base relocation table data directory that points
into the wrong section. It points inside the virtual address space
allocated for that section, but the section contains much less raw
data, and the table points outside of the provided raw data.
No longer reject such binaries (to let tools operate on them and
inspect them), but don't set the table pointers (so that when
printing e.g. base relocations, we don't print anything).
This should fix the regression pointed out in
https://reviews.llvm.org/D126898#3565834.
Differential Revision: https://reviews.llvm.org/D127345
