when the object is in an archive to use something like libx.a(foo.o) as part of
the error message.
Also changed llvm-objdump and llvm-size to be like llvm-nm and ignore non-object
files in archives and not produce any error message.
To do this Archive::Child::getAsBinary() was changed from ErrorOr<...> to
Expected<...> then that was threaded up to its users.
Converting this interface to Expected<> from ErrorOr<> does involve
touching a number of places. To contain the changes for now the use of
errorToErrorCode() is still used in one place yet to be fully converted.
Again there some were bugs in the existing code that did not deal with the
old ErrorOr<> return values. So now with Expected<> since they must be
checked and the error handled, I added a TODO and a comments for those.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269784 91177308-0d34-0410-b5e6-96231b3b80d8
load commands.
The existing test case in test/Object/macho-invalid.test for
macho-invalid-too-small-segment-load-command has a cmdsize of 55, while
being too small also it is not a multiple of 4. So when that check is added
this test case will produce a different error. So I constructed a new test case
that will trigger the intended error.
I also changed the error message to be consistent with the other malformed Mach-O
file error messages which prints the load command index. I also removed both
object_error::macho_load_segment_too_small and
object_error::macho_load_segment_too_many_sections from Object/Error.h
as they are not needed and can just use object_error::parse_failed and let the
error message string distinguish the specific error.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268652 91177308-0d34-0410-b5e6-96231b3b80d8
command has a size less than 8 bytes.
I think the existing test case in test/Object/macho-invalid.test for
macho64-invalid-too-small-load-command was trying to test for this but that
test case triggered a different error given how it was constructed. So I
constructed a new test case that would trigger this specific error.
I also changed the error message to be consistent with the other malformed Mach-O
file error messages. I also removed object_error::macho_small_load_command from
Object/Error.h as it is not needed and can just use object_error::parse_failed
and let the error message string distinguish the error.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268463 91177308-0d34-0410-b5e6-96231b3b80d8
command other than the first one is past the end of the load commands.
This is like the test case in test/Object/macho-invalid.test for
macho64-invalid-incomplete-load-command but it is the second load command
that is past the end of all the load commands instead of the first.
The code in the constructor for MachOObjectFile that loops over the load
commands used getNextLoadCommandInfo() which was not producing
a good error message. So that was fixed and a test case was added.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268403 91177308-0d34-0410-b5e6-96231b3b80d8
We used to keep both a section and a pointer to the first symbol.
The oddity of keeping a section for dynamic symbols is because there is
a DT_SYMTAB but no DT_SYMTABZ, so to print the table we have to find the
size via a section table.
The reason for still keeping a pointer to the first symbol is because we
want to be able to print relocation tables even if the section table is
missing (it is mandatory only for files used in linking).
With this patch we keep just a DynRegionInfo. This then requires
changing a few places that were asking for a Elf_Shdr but actually just
needed the first symbol.
The test change is to delete the program header pointer.
Now that we use the information of both DT_SYMTAB and .dynsym, we don't
depend on the sh_entsize of .dynsym if we see DT_SYMTAB.
Note: It is questionable if it is worth it putting the effort to report
broken sh_entsize given that in files with no section table we have to
assume it is sizeof(Elf_Sym), but that is for another change.
Extracted from r260488.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261099 91177308-0d34-0410-b5e6-96231b3b80d8
Original messages:
Revert "[readobj] Handle ELF files with no section table or with no program headers."
Revert "[readobj] Dump DT_JMPREL relocations when outputting dynamic relocations."
r260489 depends on r260488 and among other issues r260488 deleted error
handling code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@260962 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for finding the dynamic table and dynamic symbol table via
the section table or the program header table. If there's no section table an
attempt is made to figure out the length of the dynamic symbol table.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@260488 91177308-0d34-0410-b5e6-96231b3b80d8
in MachOObjectFile::getSymbolByIndex() when a Mach-O file has
a symbol table load command but the number of symbols are zero.
The code in MachOObjectFile::symbol_begin_impl() should not be
assuming there is a symbol at index 0, in cases there is no symbol
table load command or the count of symbol is zero. So I also fixed
that. And needed to fix MachOObjectFile::symbol_end_impl() to
also do the same thing for no symbol table or one with zero entries.
The code in MachOObjectFile::getSymbolByIndex() should trigger
the report_fatal_error() for programmatic errors for any index when
there is no symbol table load command and not return the end iterator.
So also fixed that. Note there is no test case as this is a programmatic
error.
The test case using the file macho-invalid-bad-symbol-index has
a symbol table load command with its number of symbols (nsyms)
is zero. Which was incorrectly testing the bad triggering of the
report_fatal_error() in in MachOObjectFile::getSymbolByIndex().
This test case is an invalid Mach-O file but not for that reason.
It appears this Mach-O file use to have an nsyms value of 11,
and what makes this Mach-O file invalid is the counts and
indexes into the symbol table of the dynamic load command
are now invalid because the number of symbol table entries
(nsyms) is now zero. Which can be seen with the existing
llvm-obdump:
% llvm-objdump -private-headers macho-invalid-bad-symbol-index
…
Load command 4
cmd LC_SYMTAB
cmdsize 24
symoff 4216
nsyms 0
stroff 4392
strsize 144
Load command 5
cmd LC_DYSYMTAB
cmdsize 80
ilocalsym 0
nlocalsym 8 (past the end of the symbol table)
iextdefsym 8 (greater than the number of symbols)
nextdefsym 2 (past the end of the symbol table)
iundefsym 10 (greater than the number of symbols)
nundefsym 1 (past the end of the symbol table)
...
And the native darwin tools generates an error for this file:
% nm macho-invalid-bad-symbol-index
nm: object: macho-invalid-bad-symbol-index truncated or malformed object (ilocalsym plus nlocalsym in LC_DYSYMTAB load command extends past the end of the symbol table)
I added new checks for the indexes and sizes for these in the
constructor of MachOObjectFile. And added comments for what
would be a proper diagnostic messages.
And changed the test case using macho-invalid-bad-symbol-index
to test for the new error now produced.
Also added a test with a valid Mach-O file with a symbol table
load command where the number of symbols is zero that shows
the report_fatal_error() is not called.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258576 91177308-0d34-0410-b5e6-96231b3b80d8
We always create archives with just he filename as the member name, but
other archives can put a more complicated path in there.
This patches handles it by computing just the filename as we do when
adding a new member.
If storing the path is important for some reason, we should probably
have an orthogonal option for doing that and do it for both old and new
members.
Fixes pr25877.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256001 91177308-0d34-0410-b5e6-96231b3b80d8
Also adds a 'trivial' ELF file. This was generated by assembling
and linking a file with the symbol main which contains a single
return instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251096 91177308-0d34-0410-b5e6-96231b3b80d8
This patch includes a fix for a llvm-readobj test. With this patch,
the tool does no longer print out COFF headers for the short import
file, but that's probably desirable because the header for the short
import file is dummy.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246283 91177308-0d34-0410-b5e6-96231b3b80d8
COFF short import files are special kind of files that contains only
DLL-exported symbol names. That's different from object files because
it has no data except symbol names.
This change implements a SymbolicFile interface for the short import
files so that symbol names can be accessed through that interface.
llvm-ar is now able to read the file and create symbol table entries
for short import files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246276 91177308-0d34-0410-b5e6-96231b3b80d8
This makes llvm-nm consistent with binutils nm on executables and DLLs.
For a vanilla hello world executable, the address of main should include
the default image base of 0x400000.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243755 91177308-0d34-0410-b5e6-96231b3b80d8
When talking about the virtual address of sections the coff spec says:
... for simplicity, compilers should set this to zero. Otherwise, it is an
arbitrary value that is subtracted from offsets during relocation.
We don't currently subtract it, so check that it is zero.
If some producer does create such files, we can change getRelocationOffset
instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241447 91177308-0d34-0410-b5e6-96231b3b80d8
This moves the error checking for string tables to getStringTable which returns
an ErrorOr<StringRef>.
This improves error checking, makes it uniform across all string tables and
makes it possible to check them once instead of once per name.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240950 91177308-0d34-0410-b5e6-96231b3b80d8
This case had been failing on testers that didn't have x86 support. Rather
than XFAIL it on testers without x86 support, I've just assembled it and used
the raw object as the test input.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240875 91177308-0d34-0410-b5e6-96231b3b80d8
The parser provides a convenient interface for reading llvm stackmap v1 sections
in object files.
This patch also includes a new option for llvm-readobj, '-stackmap', which uses
the parser to pretty-print stackmap sections for debugging/testing purposes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240860 91177308-0d34-0410-b5e6-96231b3b80d8
This patch changes getRelocationAddend to use ErrorOr and considers it an error
to try to get the addend of a REL section.
If, for example, a x86_64 file has a REL section, that file is corrupted and
we should reject it.
Using ErrorOr is not ideal since we check the section type once per relocation
instead of once per section.
Checking once per section would involve getRelocationAddend just asserting and
callers checking the section before iterating over the relocations.
In any case, this is an improvement and includes a test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240176 91177308-0d34-0410-b5e6-96231b3b80d8
Report proper error code from MachOObjectFile constructor if we
can't parse another segment load command (we already return a proper
error if segment load command contents is suspicious).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239109 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Instead, properly report this error from MachOObjectFile constructor.
Test Plan: regression test suite
Reviewers: rafael
Subscribers: llvm-commits
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239078 91177308-0d34-0410-b5e6-96231b3b80d8
We already handled a section with no symbols, extend that to also handle a
section with symbols that don't include the section start.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239039 91177308-0d34-0410-b5e6-96231b3b80d8
MachO and COFF quite reasonably only define the size for common symbols.
We used to try to figure out the "size" by computing the gap from one symbol to
the next.
This would not be correct in general, since a part of a section can belong to no
visible symbol (padding, private globals).
It was also really expensive, since we would walk every symbol to find the size
of one.
If a caller really wants this, it can sort all the symbols once and get all the
gaps ("size") in O(n log n) instead of O(n^2).
On MachO this also has the advantage of centralizing all the checks for an
invalid n_sect.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238028 91177308-0d34-0410-b5e6-96231b3b80d8
