| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
This rewrites a few tests to stop using the
trivial.obj.elf-x86-64 precompiled object
and removes it.
Differential revision: https://reviews.llvm.org/D71662
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
configured with an x86 backend.
Summary: This fixes a failure on the Builder clang-cmake-armv7-quick bot.
Reviewers: lhames, jhenderson
Reviewed By: lhames
Subscribers: kristof.beyls, rupprecht, seiya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71792
|
|
|
|
|
| |
This addresses an issue introduced in dedad08 and is needed to make
sure this test works properly on Windows.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
llvm-objdump will commonly error out when disassembling a Mach-O binary with
stab symbols, or when printing a Mach-O symbol table that includesstab symbols.
That is because the Mach-O N_OSO symbol has been modified to include the
bottom 8-bit value of the Mach-O's cpusubtype value in the section field. In
general, one cannot blindly assume a stab symbol's section field is valid
unless one has actually consulted the specification for the specific stab.
Since objdump mostly just walks the symbol table to get mnemonics for code
disassembly it's best for objdump to just ignore stab symbols. llvm-nm will
do a more complete and correct job of displaying Mach-O symbol table contents.
Reviewers: pete, lhames, ab, thegameg, jhenderson, MaskRay
Reviewed By: thegameg, MaskRay
Subscribers: MaskRay, rupprecht, seiya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71394
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
llvm-symbolizer is used by sanitizers to symbolize errors discovered by
sanitizer, but there's no way to pass options to llvm-symbolizer since
the tool is invoked directly by the sanitizer runtime. Therefore, we
don't have a way to pass options needed to find debug symbols such as
-dsym-hint or -debug-file-directory. This change enables reading options
from the LLVM_SYMBOLIZER_OPTS in addition to command line which can be
used to pass those additional options to llvm-symbolizer invocations
made by sanitizer runtime.
Differential Revision: https://reviews.llvm.org/D71668
|
|
|
|
|
|
|
|
|
|
|
| |
The debug line verbose printing was printing the wrong values for rows
added via DW_LNE_end_sequence, because the row was being printed AFTER
its state had been reset following it being appended to the line table.
This patch fixes this issue by printing the row before appending it.
Reviewers: dblaikie, MaskRay
Differential Revision: https://reviews.llvm.org/D71664
|
|
|
|
|
|
|
|
|
| |
This removes the precompiled binary used, simplifies
the first test case, adds comments and llvm-readelf tool
invocations.
It also adds a test case for checking versioning symbols.
Differential revision: https://reviews.llvm.org/D71595
|
|
|
|
|
|
|
| |
This removes 2 precompiled binaries, adds testing
for STO_* flags missing, refines and renames the test.
Differential revision: https://reviews.llvm.org/D71651
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have the `elf-dynamic-tags-machine-specific.yaml` input shared
between the llvm-readobj and llvm-objdump test.
It looks strange, because tools usually does not share inputs.
Also there are following problems related:
1) `elf-dynamic-tags-machine-specific.yaml` input contains excessive YAML parts.
2) objdump's test case never test AARCH64 tags.
3) There are unknown tags in the `elf-dynamic-tags-machine-specific.yaml` and
`dynamic-tags-machine-specific.test`, though we already testing unknown tags
in `\llvm-readobj\ELF\dynamic-tags.test` and `llvm-objdump\elf-dynamic-section.test` tests.
This patch removes the shared input and refines the test cases to resolve
issues mentioned.
Differential revision: https://reviews.llvm.org/D71602
|
|
|
|
| |
(found when LLVM fails to emit addr_base for gmlt+DWARFv5)
|
|
|
|
|
|
| |
Adding a basic lit test for MIPS.
Differential Revision: https://reviews.llvm.org/D71605
|
|
|
|
| |
I've forgot to address this review comment.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this test case we use 3 precompiled objects to
test how we print a histogram for an GNU hash section.
It does not make sense to use precompiled objects
for that. Also we could have 2 tests: one for 32 and
another for 64 bits target.
This patch does this change. It is not possible to remove
these precompiled objects because they are used elsewhere.
Differential revision: https://reviews.llvm.org/D71606
|
|
|
|
|
|
|
|
|
|
|
|
| |
SHF_X86_64_LARGE flags.
GNU uses `l` for SHF_X86_64_LARGE and `y` for SHF_ARM_PURECODE.
Lets follow.
To do this I had to refactor and refine how we print the help flags description.
It was too generic and inconsistent with GNU readelf.
Differential revision: https://reviews.llvm.org/D71464
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our logic that dumped the flags was buggy.
For LLVM style it dumped SHF_MASKPROC/SHF_MASKOS named constants, though
they are not flags, but masks.
For GNU style it was just very inconsistent with GNU which has logic
that is not straightforward. Imagine we have sh_flags == 0x90000000.
SHF_EXCLUDE ("E") has a value of 0x80000000 and SHF_MASKPROC is 0xf0000000.
GNU readelf will not print "E" or "Ep" in this case, but will print just
"p". It only will print "E" when no other processor flag is set.
I had to investigate the GNU source to find the algorithm and now our logic should
match it.
Differential revision: https://reviews.llvm.org/D71462
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 84a9756 added an extra blank line at the end of any line table.
However, a blank line is also printed after the line table header, which
meant that two blank lines in a row were being printed after a header,
if there were no rows. This patch defers the post-header blank line
printing until it has been determined that there are rows to print.
Reviewed by: dblaikie
Differential Revision: https://reviews.llvm.org/D71540
|
|
|
|
|
|
|
|
|
| |
The %update_cc_test_checks substitution only gets added if python3
is on path, so the test fails if it isn't. Don't run the test
when it would fail.
Also include the '%' in the arg to add_update_script_substition(),
to help greppability.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
llvm-cxxfilt wasn't correctly demangle COFF import thunk in those two
cases before:
* demangle in split mode (multiple words from commandline)
* the import thunk prefix was added no matter the later part of the
string can be demangled or not
Now llvm-cxxfilt should handle both case correctly.
Reviewers: compnerd, erik.pilkington, jhenderson
Reviewed By: jhenderson
Subscribers: jkorous, dexonsmith, ributzka, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71425
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This commit adds basic tests for these update script to validate that
they still work as expected. In the future we could extend these tests
whenever new features are added to avoid introducing regressions.
Reviewers: xbolva00, MaskRay, jdoerfert
Reviewed By: jdoerfert
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70660
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to write section contents
.text sh_address=0x1000 sh_offset=0x1000
.data sh_address=0x3000 sh_offset=0x2000
In an objcopy -O binary output, the distance between two sections equal
their LMA differences (0x3000-0x1000), instead of their sh_offset
differences (0x2000-0x1000). This patch changes our behavior to match
GNU.
This rule gets more complex when the containing PT_LOAD has
p_vaddr!=p_paddr. GNU objcopy essentially computes
sh_offset-p_offset+p_paddr for each candidate section, and removes the
gap before the first address.
Added tests to binary-paddr.test to catch the compatibility problem.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D71035
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: alexshap, rupprecht, jhenderson
Reviewed By: alexshap, jhenderson
Subscribers: mgorny, jakehehrlich, abrachet, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66283
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a follow up for D70548.
Currently, variables with debug info coverage between 0% and 1% are put into
zero-bucket. D70548 changed the way statistics calculate a variable's coverage:
we began to use enclosing scope rather than a possible variable life range.
Thus more variables might be moved to zero-bucket despite they have some debug
info coverage.
The patch is to distinguish between a variable that has location info but
it's significantly less than its enclosing scope and a variable that doesn't
have it at all.
Reviewers: djtodoro, aprantl, dblaikie, avl
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71070
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This changes the representation of 'coverage buckets' in llvm-dwarfdump and
llvm-locstats to one that makes more clear what the buckets contain.
See some related details in D71070.
Reviewers: djtodoro, aprantl, cmtice, jhenderson
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71366
|
|
|
|
|
|
|
| |
If the total number of PC range bytes in each variable's enclosing scope
('scope bytes total') is 0, we will have division by zero.
Differential Revision: https://reviews.llvm.org/D71415
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we have the `Flags` property that allows to
set flags for a section. The problem is that it does not
allow us to set an arbitrary value, because of bit fields
validation under the hood. An arbitrary values can be used
to test specific broken cases.
We probably do not want to relax the validation, so this
patch adds a `ShSize` property that allows to
override the `sh_size`. It is inline with others `Sh*` properties
we have already.
Differential revision: https://reviews.llvm.org/D71411
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've noticed that when we have all regular flags set, we print "WAEXMSILoGTx"
instead of "WAXMSILOGTCE" printed by GNU readelf.
It happens because:
1) We print SHF_EXCLUDE at the wrong place.
2) We do not recognize SHF_COMPRESSED, we print "x" instead of "C".
3) We print "o" instead of "O" for SHF_OS_NONCONFORMING.
This patch fixes differences and adds test cases.
Differential revision: https://reviews.llvm.org/D71418
|
|
|
|
|
|
|
|
| |
This helps delineate it in the output from later tables or other output.
Reviewed by: JDevlieghere
Differential Revision: https://reviews.llvm.org/D71344
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cleanup flags testing.
This:
1) Adds a test for testing all section flags (`section-flags.test`).
2) Renames `sec-flags.test`->`section-arch-flags.test`
and performs a clean up.
3) Removes `compression.zlib.style.elf-x86-64` binary and a test case
for SHF_COMPRESSED flag, because them are now excessive.
4) Adds missing MIPS flags and a test for SHF_ARM_PURECODE.
Differential revision: https://reviews.llvm.org/D71333
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
tools/llvm-readobj currently contains tests that are either general for
all file types or that mix file types inside. This patch refactors
these test and leaves only general tests in that folder. All other
tests were moved to ELF/COFF/MachO and wasm accordingly.
I tried to minimize amount of changes, so most of the test parts
remained unchanged. Any further refactorings and improvements for
particular tests should be done independently from this patch.
Differential revision: https://reviews.llvm.org/D71269
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A number of the --debug-* options in llvm-dwarfdump are not particularly
well tested. In some cases, the option is only tested as part of testing
another feature, or a specific part of the section that the options
dump. This change adds four new tests to address some of these holes. It
is not aiming to address every hole however.
I kept the --debug-line switch test separate to X86/brief.s because the
latter only considers the parts of the line table that are affected by
verbose printing, thus missing out things like the header and different
values for things like the Line, Column etc registers.
Reviewed by: JDevlieghere
Differential Revision: https://reviews.llvm.org/D71276
|
|
|
|
|
|
|
|
|
|
| |
errors and warnings.
After recent changes it is now seems possible to get rid of
printing '\n' before each error and warning. This makes the output
cleaner.
Differential revision: https://reviews.llvm.org/D71246
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is discussed here https://reviews.llvm.org/D71118#inline-643172
Currently when a version is empty, llvm-readelf prints:
"000: 0 (*local*) 2 (<corrupt>)"
But GNU readelf does not treat empty section as corrupt.
There is no sense in having empty versions anyways it seems, but
this change is for consistency with GNU.
Differential revision: https://reviews.llvm.org/D71243
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARMWinEHPrinter was already designed to handle linked PE images
(since d2941b43f40d), but resolving symbols didn't consistently
take the image base into account (as linked images seldom have a
symbol table, except for in MinGW setups).
Win64EHDumper wasn't really designed to handle linked images (it would
crash if executed on such a file), but a few concepts (getSymbol,
taking a virtual address instead of a relocation, and
getSectionContaining for finding the section containing a certain
virtual address) can be borrowed from ARMWinEHPrinter.
Adjust ARMWinEHPrinter to print the address of the exception handler
routine as a VA instead of an RVA, consistently with other addresses
in the same printout, and make Win64EHDumper print addresses similarly
for image cases.
Differential Revision: https://reviews.llvm.org/D71303
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If llvm-ar is installed at arm-pokymllib32-linux-gnueabi-llvm-ar, it may
think it is llvm-lib due to the "lib" substring.
Improve the heuristic to make all the following work as intended:
llvm-ar-9 (llvm-9 package on Debian)
llvm-ranlib.exe
Lib.exe (reported by D44808)
arm-pokymllib32-linux-gnueabi-llvm-ar (reported by D71030)
Reviewed By: raj.khem, rupprecht
Differential Revision: https://reviews.llvm.org/D71302
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D71202
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patch adds an object file (in yaml format) with a synthetic
.debug_info section which we use to test that the supported RISC-V relocations
are properly resolved.
Reviewers: asb, lenary, MaskRay
Reviewed By: MaskRay
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70541
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
related to versioning.
I was investigating a change previously discussed that eliminates an excessive
empty lines from the output when we report warnings and errors
(https://reviews.llvm.org/D70826#inline-639055) and found
that we need this refactoring or alike to achieve that.
The problem is that some of our functions that finds symbol versions just
fail instead of returning errors or printing warnings. Another problem
is that they might print a warning on the same line with the regular output.
In this patch I've splitted getting of the version information and dumping of it
for GNU printVersionSymbolSection(). I had to change a few methods to return
Error or Expected<> to do that properly.
Differential revision: https://reviews.llvm.org/D71118
|
|
|
|
|
| |
It was missing on the first test invocation. The flag is necessary to
ignore line-ending differences on Windows.
|
|
|
|
|
|
|
|
|
|
|
|
| |
separate folders.
This creates the next subfolders in the test directory:
"COFF", "ELF", "MachO", "wasm".
I've also removed platform specific prefixes, like "coff-*".
One unused binary was removed as well: `Inputs/relocs.obj.elf-mips`
Differential revision: https://reviews.llvm.org/D71203
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently dwarfdump uses the ArchType to filter out architectures, which
is problematic for architectures like arm64e and x86_64h that map back
to arm64 and x86_64 respectively. The result is that the filter doesn't
work for these architectures because it matches all the variants. This
is especially bad because usually these architectures are the reason to
use the filter in the first place.
Instead, we should match the architecture based on the string name. This
means the filter works for the values printed by dwarfdump. It has the
unfortunate side effect of not working for aliases, like AArch64, but I
think that's worth the trade-off.
rdar://53653014
Differential revision: https://reviews.llvm.org/D71230
|
|
|
|
| |
See also e84468c1f.
|
|
|
|
|
|
|
|
| |
When committing dba420bc05ae, I missed that a darwin-specific change had
been recently introduced into llvm-cxxfilt, which my change ignored and
consequently broke the darwin build bot. This change fixes this issue as
well as improving naming/commenting of things related to this point so
that people are less likely to run into the same issue as I did.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CodeGenPrepare::placeDebugValues moves variable location intrinsics to be
immediately after the Value they refer to. This makes tracking of locations
very easy; but it changes the order in which assignments appear to the
debugger, from the source programs order to the order in which the
optimised program computes values. This then leads to PR43986 and PR38754,
where variable locations that were in a conditional block are made
unconditional, which is highly misleading.
This patch adjusts placeDbgValues to only re-order variable location
intrinsics if they use a Value before it is defined, significantly reducing
the damage that it does. This is still not 100% safe, but the rest of
CodeGenPrepare needs polishing to correctly update debug info when
optimisations are performed to fully fix this.
This will probably break downstream debuginfo tests -- if the
instruction-stream position of variable location changes isn't the focus of
the test, an easy fix should be to manually apply placeDbgValues' behaviour
to the failing tests, moving dbg.value intrinsics next to SSA variable
definitions thus:
%foo = inst1
%bar = ...
%baz = ...
void call @llvm.dbg.value(metadata i32 %foo, ...
to
%foo = inst1
void call @llvm.dbg.value(metadata i32 %foo, ...
%bar = ...
%baz = ...
This should return your test to exercising whatever it was testing before.
Differential Revision: https://reviews.llvm.org/D58453
|
|
|
|
|
|
|
|
|
|
|
| |
Mostly this adds testing for certain aliases in more explicit ways.
There are also a few tidy-ups, and additions of missing testing, where
the feature was either not tested at all, or not tested explicitly and
sufficiently.
Reviewed by: MaskRay, rupprecht, grimar
Differential Revision: https://reviews.llvm.org/D71116
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The patch removes OffsetToFirstDefinition in the 'scope bytes total'
statistic computation. Thus it unifies the way the scope and the coverage
buckets are computed. The rationals behind that are the following:
1. OffsetToFirstDefinition was used to calculate the variable's life range.
However, there is no simple way to do it accurately, so the scope calculated
this way might be misleading. See D69027 for more details on the subject.
2. Both 'scope bytes total' and coverage buckets seem to be intended
to represent the same data in different ways. Otherwise, the statistics
might be controversial and confusing.
Note that the approach gives up a thorough evaluation of debug information
completeness (i.e. coverage buckets by themselves doesn't tell how good
the debug information is). Only changes in coverage over time make
a 'physical' sense.
Reviewers: djtodoro, aprantl, vsk, dblaikie, avl
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70548
|
|
|
|
|
|
|
| |
This introduce a new helper which is used to parse the SHT_GNU_versym section.
LLVM/GNU styles implementations now use it to share the logic.
Differential revision: https://reviews.llvm.org/D71054
|
|
|
|
|
|
|
|
|
|
| |
There is no way to dump SHT_LLVM_DEPENDENT_LIBRARIES sections
currently. This patch implements this.
The section is described here:
https://llvm.org/docs/Extensions.html#sht-llvm-dependent-libraries-section-dependent-libraries
Differential revision: https://reviews.llvm.org/D70665
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: hubert.reinterpretcast
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71036
|
|
|
|
|
|
|
|
|
|
| |
The following changes enable llvm-ifs to handle the following merge conflicts:
* Weak + Strong symbol merging for the same symbol
* empty vs non-empty triple field
* empty vs non-empty object file format
Differential Revision: https://reviews.llvm.org/D70834
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently these function return the raw content of the appropriate table
header, which means they are relative to the DW_AT_{loc,rng}list_base,
and one has to relocate them in order to do anything.
This changes the functions to perform the relocation themselves, which
seems more clearer, particularly as they are sitting right next to the
find{Rng,Loc}listFromOffset functions, but one *cannot* simply take the
result of these functions and take pass them there.
The only effect of this patch is to change what value is dumped for the
DW_AT_ranges attribute, which I think is for the better, as previously
the values appeared to point into thin air.
(The main reason I am looking at this is because I was trying to
implement equivalent functionality in lldb's DWARFUnit, and was stumped
by this behavior.
Reviewers: dblaikie, JDevlieghere, aprantl
Subscribers: hiraditya, llvm-commits, SouraVX
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71006
|