This program is for testing features that rely on multi-module bitcode files.
It takes a multi-module bitcode file, extracts one of the modules and writes
it to the output file.
Differential Revision: https://reviews.llvm.org/D26778
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288201 91177308-0d34-0410-b5e6-96231b3b80d8
In some cases the leading headers of the file name, archive member and
architecture slice name in the output of lvm-objdump is not wanted so the
tool’s output can be directly used by scripts. This matches the -X option
of the Apple otool(1) program.
rdar://28491674
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288199 91177308-0d34-0410-b5e6-96231b3b80d8
Undefined and weak symbols don't have a meaningful size or value.
As such, nothing should be printed for those attributes (this is
already done for the address with 'U') with the BSD format. This
matches what GNU nm does.
Note that for the POSIX.2 format [1] zero values are still
printed for the size and value. This seems in spirit with
the format strings in that specification, but is debatable.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/
Differential Revision: https://reviews.llvm.org/D26936
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287802 91177308-0d34-0410-b5e6-96231b3b80d8
-symbols prints both .symtab and .dynsym symbols for GNU style in ELF.
-dyn-symbols prints symbols looking up through hash tables. This helps validate hash tables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287786 91177308-0d34-0410-b5e6-96231b3b80d8
This commit makes llvm-cov avoid showing 0% (0/0) coverage for things
like file function coverage, etc. in reports and HTML output. This can happen
for files like headers that have macros but no functions. This commit makes
llvm-cov report - (0/0) instead.
rdar://29246480
Differential Revision: https://reviews.llvm.org/D26615
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287539 91177308-0d34-0410-b5e6-96231b3b80d8
No real functional change with this commit.
The problem with report_fatal_error() is it does not include the tool name
and the file name the for which the error message was generated.
Uses of report_fatal_error() were change to report_error() or error()
to get a better error and to make the code smaller and cleaner.
Also changed things like error(errorToErrorCode(SOrErr.takeError())) to
use report_error() with a file name and the llvm::Error (as well as the
ArchitectureName if available) so the error message is printed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287163 91177308-0d34-0410-b5e6-96231b3b80d8
Rather than using sed to generate the input and pipe the result to
strings, use the static input instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287079 91177308-0d34-0410-b5e6-96231b3b80d8
To get a good error message for all files that could contain Mach-O
files the code in llvm-objdump needs to use the archive member name
and name of the architecture of a slice of a universal file in those cases
where the error come from a Mach-O file in an archive or a universal file.
Most of this is fixed by moving the call to checkSymbolTable() into
ProcessMachO() and calling it when the operation needs the symbol
table. And then calling the form of report_error() that has the
ArchiveName and ArchitectureName arguments. One other place
needed to call this form of report_error() also with these arguments.
Also changed the code in MachODump.cpp to not use report_fatal_error()
and use report_error() instead to make the code smaller and cleaner. All
cases of this are for errors with the symbol table which should now never
be tripped since checkSymbolTable() should be called first to get a good
error message in these cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287050 91177308-0d34-0410-b5e6-96231b3b80d8
Permit specifying the match length (the `-n` or `--bytes` option). The
deprecated `-[length]` form is not supported as an option. This allows the
strings tool to display only the specified length strings rather than the
hardcoded default length of >= 4.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286914 91177308-0d34-0410-b5e6-96231b3b80d8
Change the dynamic files to static in the hope that it will actually fix the
transient errors that Ive been unable to reproduce.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286891 91177308-0d34-0410-b5e6-96231b3b80d8
The philosophy of the error checking in libObject for Mach-O files
is that the constructor will check the load commands so for their
tables the offsets and sizes are properly contained in the file.
But there is no checking of the entries of any of the tables.
For the contents of the tables themselves the methods accessing
the contents of the entries return errors as needed. In some
cases this however makes it difficult or cumbersome to produce
a good error message which would include the tool name, file name,
archive member, and name of the architecture of a slice of a universal file
the error occurred in.
So idea is that there will be a method to check a table which can
be called up front before using it allowing a good error message
to be produced before a table is used. And if only verification of
the Mach-O file and its tables are wanted a new possible method
checkAllTables() could be added to call all of the methods to
check all the tables at some time when such methods exist.
The checkSymbolTable() is the first of such methods to check
one of the Mach-O file tables. This method initially will used in
llvm-objdump’s DisassembleMachO() routine before it gets the
section and symbol information. As if there are problems with
the symbol table currently the error is first encountered by the
bool operator() in the SymbolSorter() struct which passed to
std::sort(). In this case there is no context as to the file name
the symbol which results a poor error message:
LLVM ERROR: truncated or malformed object (bad string index: 22 for symbol at index 1)
with the added call to the checkSymbolTable() method the
error message includes the tool name and file name:
llvm-objdump: 'macho-invalid-symbol-strx': truncated or malformed object (bad string table index: 22 past the end of string table, for symbol at index 1)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286887 91177308-0d34-0410-b5e6-96231b3b80d8
Also,
Revert "test: remove the archive before modifying it"
Revert "test: explicitly use gnu format"
This reverts commits r286778, r286729 and r286767, as they are randomly failing
on many bots (AArch64, x86_64).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286820 91177308-0d34-0410-b5e6-96231b3b80d8
The archive may already exist when not doing a clean test run. The dirty state
can cause a test failure. Remove the archive first.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286778 91177308-0d34-0410-b5e6-96231b3b80d8
`c++filt` when given no arguments runs as a REPL, decoding each line as a
decorated name. Unify the test structure to be more uniform, with the tests for
llvm-cxxfilt living under test/tools/llvm-cxxfilt.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286777 91177308-0d34-0410-b5e6-96231b3b80d8
Until we have handling for ignoring unloaded sections, simplify the logic to
the point of triviality. This fixes the scanning of archives, particularly when
embedded in archives.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286727 91177308-0d34-0410-b5e6-96231b3b80d8
We would ignore the last string that appeared if the file ended with a printable
character. Ensure that we get the last string.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286706 91177308-0d34-0410-b5e6-96231b3b80d8
in llvm-objdump for Mach-O files add the printing of the
ARM_THREAD_STATE64 in the same format as
otool-classic(1) on darwin.
To do this the 64-bit ARM general tread state
needed to be defined in include/llvm/Support/MachO.h .
rdar://28985800
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285967 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285860 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
There is no point to importing at -O0, since we won't inline. We should
also disable other cross-module optimizations.
(Plan to backport this fix to the 3.9 branch to fix PR30774)
Reviewers: pcc
Subscribers: johanengelen, mehdi_amini
Differential Revision: https://reviews.llvm.org/D25918
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285648 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
When we have an aliasee that is linkonce, while we can't convert
the non-prevailing copies to available_externally, we still need to
convert the prevailing copy to weak. If a reference to the aliasee
is exported, not converting a copy to weak will result in undefined
references when the linkonce is removed in its original module.
Add a new test and update existing tests.
Reviewers: mehdi_amini
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D26076
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285512 91177308-0d34-0410-b5e6-96231b3b80d8
Most of the version of report_error were quoting the filename and
printing a colon between the file name and the error message, but this
one wasn't doing either of those. Fix the output to be more
consistent.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285252 91177308-0d34-0410-b5e6-96231b3b80d8
On Windows, "no such file or directory" is the default error translation
as opposed to the capitalized form on Linux.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285174 91177308-0d34-0410-b5e6-96231b3b80d8
Usage:
llvm-xray extract <object file> [-o <filename or '-'>]
The tool gets the XRay instrumentation map from an object file and turns
it into YAML. We first support ELF64 sleds on x86_64 binaries, with
provision for supporting other supported platforms and formats later.
This is the first of a many-part change to fully implement the
`llvm-xray` tool.
We also define a subcommand registration and dispatch mechanism to be
used by other further subcommand implementations for llvm-xray.
Diffusion Revision: https://reviews.llvm.org/D21987
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285165 91177308-0d34-0410-b5e6-96231b3b80d8
Usage:
llvm-xray extract <object file> [-o <filename or '-'>]
The tool gets the XRay instrumentation map from an object file and turns
it into YAML. We first support ELF64 sleds on x86_64 binaries, with
provision for supporting other supported platforms and formats later.
This is the first of a many-part change to fully implement the
`llvm-xray` tool.
We also define a subcommand registration and dispatch mechanism to be
used by other further subcommand implementations for llvm-xray.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285155 91177308-0d34-0410-b5e6-96231b3b80d8
Not all echo commands support "-e". On the other hand, printf
command is in POSIX, so it's more portable than "echo -e".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285151 91177308-0d34-0410-b5e6-96231b3b80d8
When we load coverage data from multiple objects, we don't have a way to
attribute a source object to a function record. Printing out the object
filename next to the source filename is already not very useful: soon,
it'll actually become misleading. Stop printing out the filename now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285043 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Add relocations for AArch64 ILP32. Includes:
- Addition of definitions for R_AARCH32_*
- Definition of new -target-abi: ilp32
- Definition of data layout string
- Tests for added relocations. Not comprehensive, but matches
existing tests for 64-bit. Renames "CHECK-OBJ" to "CHECK-OBJ-LP64".
- Tests for llvm-readobj
Reviewers: zatrazz, peter.smith, echristo, t.p.northover
Subscribers: aemerson, rengolin, mehdi_amini
Differential Revision: https://reviews.llvm.org/D25159
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284973 91177308-0d34-0410-b5e6-96231b3b80d8
Fix the implementation of OptReportLocationInfo's operator < so that contexts
with different unroll counts are reported separately.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284957 91177308-0d34-0410-b5e6-96231b3b80d8
iterating over an archive with object and non-object members that
would cause an Abort because to was not calling consumeError()
when the code was wanting to ignore a non-object file.
Found by Justin Bogner!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284867 91177308-0d34-0410-b5e6-96231b3b80d8
the ARM_THREAD_STATE in the same format as
otool-classic(1) on darwin.
Also remove an extra space in printing the initprot to make
the output match otool-classic(1) on darwin.
rdar://28851457
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284852 91177308-0d34-0410-b5e6-96231b3b80d8
Profile runtime can generate an empty raw profile (when there is no function in
the shared library). This empty profile is treated as a text format profile. A
test format profile without the flag of "#IR" is thought to be a clang
generated profile. So in llvm profile merging, we will get a bogus warning of
"Merge IR generated profile with Clang generated profile."
The fix here is to skip the empty profile (when the buffer size is 0) for
profile merge.
Reviewers: vsk, davidxl
Differential Revision: http://reviews.llvm.org/D25687
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284659 91177308-0d34-0410-b5e6-96231b3b80d8
This is just a quick utility handy for getting rough summaries of types
in a given object or dwo file. I've been using it to investigate the
amount of type info redundancy across a project build, for example.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284537 91177308-0d34-0410-b5e6-96231b3b80d8
Because screen space is precious, if an optimization (vectorization, for
example) never happens, don't leave empty space for the associated markers on
every line of the output. This makes the output much more compact, and allows
for the later inclusion of markers for more (although perhaps rare)
optimizations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283626 91177308-0d34-0410-b5e6-96231b3b80d8
In the left part of the reports, we have things like U<number>; if some of
these numbers use more digits than others, we don't want a space in between the
U and the start of the number. Instead, the space should come afterward. This
way it is clear that the number goes with the U and not any other optimization
indicator that might come later on the line.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283518 91177308-0d34-0410-b5e6-96231b3b80d8
As this is intended to be a user-facing option, -no-demangle seems much better
than -demangle=0. Add testing for the option.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283516 91177308-0d34-0410-b5e6-96231b3b80d8
When there are multiple optimizations on one line, record the vectorization
factors, etc. correctly (instead of incorrectly substituting default values).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283443 91177308-0d34-0410-b5e6-96231b3b80d8