Object/invalid.test is a test case that is used to check the behavior of tools
when broken inputs are used.
The most often tool tested there is llvm-readobj. I think we might want to move
such tests to test\tools\llvm-readobj. For now this patch converts
many sub-tests to use YAML and removes 12 binaries from the inputs.
Differential revision: https://reviews.llvm.org/D63762
llvm-svn: 364522
If dynamic table is missing, output "dynamic strtab not found'. If the index is
out of range, output "Invalid Offset<..>".
https://bugs.llvm.org/show_bug.cgi?id=40807
Reviewed by: jhenderson, grimar, MaskRay
Differential Revision: https://reviews.llvm.org/D63084
Patch by Yuanfang Chen.
llvm-svn: 363374
llvm-lib now needs a `target triple` for bitcode, so add a new file
that's like trivial.ll but has one, and use that in the test.
(trivial.ll had a comment that looked like it wasn't supposed to be used
in tests directly, so I don't want to change that file.)
llvm-svn: 362809
This is a result of what I found during my work on https://bugs.llvm.org/show_bug.cgi?id=41679.
Previously LLVM readelf took the information about .dynamic section
from its PT_DYNAMIC segment only. GNU tools have a bit different logic.
They also use the information from the .dynamic section header if it is available.
This patch changes the code to improve the compatibility with the GNU Binutils.
Differential revision: https://reviews.llvm.org/D61937
llvm-svn: 361165
This adds support for the arm64_32 watchOS ABI to LLVM's low level tools,
teaching them about the specific MachO choices and constants needed to
disassemble things.
llvm-svn: 360663
This updates the StackMap parser in the llvm-readobj tool to parse version 3 StackMaps, which were bumped in https://reviews.llvm.org/D32629.
Version 3 StackMaps differ in that they have a uint16 sized "location size" field which was added to the Location block in a StackMap record. The record has additional padding for alignment. This was a backwards incompatible change resulting in a StackMap version bump.
Patch By: jacob.hughes@kcl.ac.uk (with a rewrite of tests by me)
Differential Revision: https://reviews.llvm.org/D59020
llvm-svn: 358325
Currently, this fails with many tools, e.g.
$ clang -fembed-bitcode-marker -c -o test.o test.c
$ nm test.o
nm: test.o The file was not recognized as a valid object file
-fembed-bitcode-marker creates a LLVM,bitcode section consisting of a single
byte. When reading the object file, IRObjectFile::findBitcodeInObject succeeds,
causing SymbolicFile::createSymbolicFile to try to read the "bitcode" rather
than using the outer Mach-O data - when then fails.
Fix this by making findBitcodeInObject return an error if the section size <= 1.
Patched by: Nicholas Allegra
Differential Revision: https://reviews.llvm.org/D44373
llvm-svn: 356718
Summary:
guessLibraryShortName() separates a full Mach-O dylib install name path
into a short name and a dyld image suffix. The short name is the name
of the dylib without its path or extension. The dyld image suffix is a
string used by dyld to load variants of dylibs if available at runtime;
for example, "when binding this process, load 'debug' variants of all
required dylibs." dyld knows exactly what the image suffix is, but
by convention diagnostic tools such as llvm-nm attempt to guess suffix
names by looking at the install name path.
These dyld image suffixes are separated from the short name by a '_'
character. Because the '_' character is commonly used to separate words
in filenames guessLibraryShortName() cannot reliably separate a dylib's
short name from an arbitrary image suffix; imagine if both the short
name and the suffix contains an '_' character! To better deal with this
ambiguity, guessLibraryShortName() will recognize only "_debug" and
"_profile" as valid Suffix values. Calling code needs to be tolerant of
guessLibraryShortName() guessing incorrectly.
The previous implementation of guessLibraryShortName() did not allow
'_' characters to appear in short names. When present, the short name
would be truncated, e.g., "libcompiler_rt" => "libcompiler". This
change allows "libcompiler_rt" and "libcompiler_rt_debug" to both be
recognized as "libcompiler_rt".
rdar://47412244
Reviewers: kledzik, lhames, pete
Reviewed By: pete
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D56978
llvm-svn: 352104
Summary:
This patch checks if the section order is correct when reading a wasm
object file in `WasmObjectFile` and converting YAML to wasm object in
yaml2wasm. (It is not possible to check when reading YAML because it is
handled exclusively by the YAML reader.)
This checks the ordering of all known sections (core sections + known
custom sections). This also adds section ID DataCount section that will
be scheduled to be added in near future.
Reviewers: sbc100
Subscribers: dschuff, mgorny, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D54924
llvm-svn: 349221
Summary:
This updates generated binaries and corresponding test cases up to date
after applying FixFunctionBitcasts pass.
Reviewers: sbc100
Subscribers: dschuff, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D54070
llvm-svn: 346286
When reading a custom WASM section, it was possible that its name
extended beyond the size of the section. This resulted in a bogus value
for the section size due to the size overflowing.
Fixes heap buffer overflow detected by OSS-fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8190
Differential revision: https://reviews.llvm.org/D50387
llvm-svn: 339269
Summary: The final -wasm component has been the default for some time now.
Subscribers: jfb, dschuff, jgravelle-google, eraman, aheejin, JDevlieghere, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D46342
llvm-svn: 332007
Summary: Also test for symbols information in test/MC/WebAssembly/debug-info.ll.
Subscribers: jfb, dschuff, jgravelle-google, aheejin, sunfish, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D46160
llvm-svn: 331005
This is required in order to enable relocs to be validated
as they are read in.
Also update tests with new section ordering.
Differential Revision: https://reviews.llvm.org/D43940
llvm-svn: 326694
This is combination of two patches by Nicholas Wilson:
1. https://reviews.llvm.org/D41954
2. https://reviews.llvm.org/D42495
Along with a few local modifications:
- One change I made was to add the UNDEFINED bit to the binary format
to avoid the extra byte used when writing data symbols. Although this
bit is redundant for other symbols types (i.e. undefined can be
implied if a function or global is a wasm import)
- I prefer to be explicit and consistent and not have derived flags.
- Some field renaming.
- Some reverting of unrelated minor changes.
- No test output differences.
Differential Revision: https://reviews.llvm.org/D43147
llvm-svn: 325860
The ELF specification says that all ELF data structures are aligned to
their natural alignments both in memory and file. That means when we
access mmap'ed ELF files, we could assume that all data structures are
aligned properly.
However, in reality, we assume that the data structures are aligned only
to two bytes because .a files only guarantee that their member files are
aligned to two bytes in archive files. So the data access is already
unaligned.
This patch relaxes the alignment requirement even more, so that we
accept unaligned access to all ELF data structures.
This patch in particular makes lld bug-compatible with icc. Intel C
compiler doesn't seem to care about data alignment and generates unaligned
relocation sections (https://bugs.llvm.org/show_bug.cgi?id=35854).
I also saw another instance of compatibility issues with our internal tool
which creates unaligned section headers.
Because GNU linkers are not picky about alignment, looks like it is
not uncommon that ELF-generating tools create unaligned files.
There is a performance penalty with this patch on host machines on which
unaligned access is expensive. x86 and AArch64 are fine. ARMv6 is a
problem, but I don't think using ARMv6 machines as hosts is common, so I
believe it's not a real problem.
Differential Revision: https://reviews.llvm.org/D41978
llvm-svn: 322407
Ensure the program_headers call will fail correctly if the program
headers are larger than the underlying buffer.
Patch by Parker Thompson!
llvm-svn: 315012
For each checked-in wasm file, make sure the there is
corresponding .ll file that can be used to regenerate it
if needed.
Add test/Object/Inputs/trivial-object-test.wasm to match other
formats and add some new wasm tests in test/Object.
Differential Revision: https://reviews.llvm.org/D35213
llvm-svn: 307585
Running `llvm-readobj -coff-directives msvcrt.lib` resulted in this error:
Invalid data was encountered while parsing the file
This happened because some of the object files in the archive have empty
`.drectve` sections. These empty sections result in a `parse_failed` error being
returned from `COFFObjectFile::getSectionContents()`, which in turn caused
`llvm-readobj` to stop. With this change, `getSectionContents` now returns
success, and like before the resulting array is empty.
Patch by Dave Lee.
Differential Revision: https://reviews.llvm.org/D32652
llvm-svn: 303014
On Solaris ld (and some other tools that use the underlying utility
libraries, such as elfdump) chokes on an archive library that has no
symbol table. The Solaris tools always create one, even if it's empty.
That bug has been fixed in the latest development line, and can
probably be backported to a supported release, but it would be nice if
LLVM's archiver could emit the empty symbol table, too.
Patch by Danek Duvall!
llvm-svn: 297773
R_X86_64_NONE can be emitted without a symbol associated (well,
in theory it should never be emitted in an ABI-compliant relocatable
object). So, if there's no symbol associated to a reloc, emit one
with an empty name, instead of crashing.
Ack'ed by Michael Spencer offline.
PR: 31768
llvm-svn: 293224
It describes a region of arbitrary data included in a Mach-O file.
Its initial use is to record extra data in MH_CORE files.
rdar://30001545
rdar://30001731
llvm-svn: 292500
These are OpenBSD specific program headers.
OpenBSD commit:
d39116912b
It is required for fixing PR31288.
Differential revision: https://reviews.llvm.org/D27456
llvm-svn: 288831
Add the checking for both the MachO::fat_header and the
MachO::fat_arch struct values in the constructor for
MachOUniversalBinary. Such that when the constructor
for ObjectForArch is called it can assume the values in
the MachO::fat_arch for the offset and size are contained
in the file after the MachOUniversalBinary constructor
is called for the Parent.
llvm-svn: 288084
the offsets and sizes of an element of the Mach-O file overlaps with
another element in the Mach-O file.
Some other tests for malformed Mach-O files now run into these
checks so their tests were also adjusted.
llvm-svn: 285860
the offsets and sizes of an element of the file overlaps with
another element in the Mach-O file.
This shows the approach to this testing for three elements
and contains for tests for their overlap. Checking for all the
remain elements will be added next.
llvm-svn: 285632
with fix: edited invalid-section-index2.elf input to pass the new check and
fail on the same place it was intended to fail.
Original commit message:
Elf.h already has code checking that section table does not go past end of file.
Problem is that this check may not work on values greater than UINT64_MAX / Header->e_shentsize
because of calculation overflow.
Parch fixes the issue.
Differential revision: https://reviews.llvm.org/D25432
llvm-svn: 285586
obsolete load commands.
Again the philosophy of the error checking in libObject for
Mach-O files, the idea behind the checking is that we never
will return a Mach-O file out of libObject that contains unknown
things the library code can’t operate on. So known obsolete
load commands will cause a hard error.
Also to make things clear I have added comments to the
values and structures in Support/Mach-O.h and
Support/MachO.def as to what is obsolete.
As noted in a TODO in the code, there may need to be a
non-default mode to allow some unknown values for well
structured Mach-O files with things like unknown load
load commands. So things like using an old lldb on a newer
Mach-O file could still provide some limited functionality.
llvm-svn: 285342
Elf.h already has code checking that section table does not go past end of file.
Problem is that this check may not work on values greater than UINT64_MAX / Header->e_shentsize
because of calculation overflow.
Parch fixes the issue.
Differential revision: https://reviews.llvm.org/D25432
llvm-svn: 285285
Revealed using "id_000038,sig_11,src_000015,op_havoc,rep_16" from PR30540,
when sh_size was 0, crash happened.
Differential revision: https://reviews.llvm.org/D25091
llvm-svn: 285282
George Rimar