| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this change, there are a few tests called llvm-symbolizer* in
the DebugInfo test area. These really were testing either the DebugInfo
or Symbolizer library, rather than the llvm-symbolizer tool itself, so
this patch renames them to be clearer that they aren't explicitly tests
for llvm-symbolizer (such tests belong in test/tools/llvm-symbolizer).
This patch also reinstates the copying of a DWO file, removed previously
in r352752. The test needs this so that it could possibly fail.
Finally, some of the tests have been simplified slightly by removing
unnecessary switches and/or unused check-prefixes.
Reviewed by: dblaikie
Differential Revision: https://reviews.llvm.org/D57518
llvm-svn: 352847
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#3)
This is the fourth (and final for now) of a series of patches
simplifying llvm-symbolizer tests. See r352752, r352753 and 352754 for
the previous ones. This patch splits out several more distinct test
cases from llvm-symbolizer.test into separate tests, and simplifies them
in various ways including:
1) Building a test case for spaces in path from source, rather than
using a pre-canned binary. This allows deleting of said binary and the
source it was built from.
2) Switching to specifying addresses and objects directly on the
command-line rather than via stdin.
This also adds an explict test for the ability to specify a file and
address as a line in stdin, since the majority of the tests have been
migrated away from this approach, leaving this largely untested.
Reviewed by: dblaikie
Differential Revision: https://reviews.llvm.org/D57446
llvm-svn: 352756
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#2)
This is the third of a series of patches simplifying llvm-symbolizer
tests. See r352752 and r352753 for the previous two. This patch splits
out a number of distinct test cases from llvm-symbolizer.test into
separate tests, and simplifies them in various ways including:
1) using --obj/positional arguments for the input file and addresses
instead of stdin,
2) using runtime-generated inputs rather than a pre-canned binary, and
3) testing more specifically (i.e. checking only what is interesting to
the behaviour changed in the original commit for that test case).
This patch also removes the test case for using --obj. The
tools/llvm-symbolizer/basic.s test already tests this case. Finally,
this patch adds a simple test case to the demangle switch test case to
show that demangling happens by default.
See https://bugs.llvm.org/show_bug.cgi?id=40070#c1 for the motivation.
Reviewed by: dblaikie
Differential Revision: https://reviews.llvm.org/D57446
llvm-svn: 352754
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#1)
This is the second of a series of patches simplifying llvm-symbolizer
tests. See r352752 for the first. This one splits out 5 distinct test
cases from llvm-symbolizer.test into separate tests, and simplifies them
slightly by using --obj/positional arguments for the input file and
addresses instead of stdin.
See https://bugs.llvm.org/show_bug.cgi?id=40070#c1 for the motivation.
Reviewed by: dblaikie
Differential Revision: https://reviews.llvm.org/D57443
llvm-svn: 352753
|
|
|
|
|
|
|
|
|
|
| |
directly (without a piped input file)
Pulling out the split-dwarf tests by way of example of how I think
llvm-symbolizer should be tested going forward. Open to
debate/discussion, though.
llvm-svn: 352004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes https://bugs.llvm.org/show_bug.cgi?id=40072.
GNU addr2line's --functions switch is off by default, has a short alias
of -f, and does not take an argument. This patch changes llvm-symbolizer
to allow the second and third point (changing the default behaviour may
have negative impacts on users). If the option is missing a value, it
now treats it as "linkage".
This change does cause one previously valid command-line to behave
differently. Before --functions <value> was accepted, but now only
--functions=<value> is allowed (as well as --functions). The old
behaviour will result in the value being treated as a positional
argument.
The previous testing for --functions=short has been pulled out into a
new test that also tests the other accepted values and option formats.
Reviewed by: ruiu
Differential Revision: https://reviews.llvm.org/D57049
llvm-svn: 351968
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Provides -no-demangle as alias for -demangle=false. Motivation: https://bugs.llvm.org/show_bug.cgi?id=40075
Reviewers: jhenderson, ruiu
Reviewed By: jhenderson
Subscribers: erik.pilkington, rupprecht, llvm-commits
Differential Revision: https://reviews.llvm.org/D56773
llvm-svn: 351735
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Provides -C as alias to -demangle. Motivation: https://bugs.llvm.org/show_bug.cgi?id=40069.
Reviewers: jhenderson, ruiu, rnk, fjricci
Reviewed By: jhenderson, ruiu
Subscribers: rupprecht, erik.pilkington, llvm-commits
Differential Revision: https://reviews.llvm.org/D56591
llvm-svn: 351300
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CU is empty (devoid of code addresses)
Originally committed in r349333, reverted in r349353.
GCC emitted these unconditionally on/before 4.4/March 2012
Clang emitted these unconditionally on/before 3.5/March 2014
This improves performance when parsing CUs (especially those using split
DWARF) that contain no code ranges (such as the mini CUs that may be
created by ThinLTO importing - though generally they should be/are
avoided, especially for Split DWARF because it produces a lot of very
small CUs, which don't scale well in a bunch of other ways too
(including size)).
The revert was due to a (Google internal) test that had some checked in old
object files missing DW_AT_ranges. That's since been fixed.
llvm-svn: 349968
|
|
|
|
|
|
|
|
|
| |
CU is empty (devoid of code addresses)"
This reverts commit r349333. It caused internal test to fail. I have
sent more information to the author.
llvm-svn: 349353
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
empty (devoid of code addresses)
GCC emitted these unconditionally on/before 4.4/March 2012
Clang emitted these unconditionally on/before 3.5/March 2014
This improves performance when parsing CUs (especially those using split
DWARF) that contain no code ranges (such as the mini CUs that may be
created by ThinLTO importing - though generally they should be/are
avoided, especially for Split DWARF because it produces a lot of very
small CUs, which don't scale well in a bunch of other ways too
(including size)).
llvm-svn: 349333
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM always puts function definition DIEs at the top level, but under
some circumstances GCC does not (at least in this case with member
functions of a function-local type).
To ensure that doesn't appear as though the local type's member function
is unduly inlined within the outer function - ensure the inline
discovery DIE parent walk stops at the first DW_TAG_subprogram.
llvm-svn: 331291
|
|
|
|
|
|
| |
(context around the %T removal here: https://reviews.llvm.org/D35396 )
llvm-svn: 312828
|
|
|
|
|
|
| |
failure.
llvm-svn: 310956
|
|
|
|
|
|
|
|
|
|
| |
The %T lit expansion expands to a common directory shared between all the tests in the same directory, which is unexpected and unintuitive, and more importantly, it's been a source of subtle race conditions and flaky tests. In https://reviews.llvm.org/D35396, it was agreed that it would be best to simply ban %T and only keep %t, which is unique to each test. When a test needs a temporary directory, it can just create one using mkdir %t.
This patch removes %T in llvm.
Differential Revision: https://reviews.llvm.org/D36495
llvm-svn: 310953
|
|
|
|
|
|
|
|
|
| |
Followup to r309570, fixing it slightly differently (ranges_base and
addr_base should never be read from a DWO file - so there shouldn't be
any issue with 'overriding' the values - conditionalize the code and
assert that the values aren't being overriden).
llvm-svn: 309879
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you've archived the DWP file somewhere it's probably useful to be
able to just tell llvm-symbolizer where it is when you're symbolizing
stack traces from the binary.
This only provides a mechanism for specifying a single DWP file, good if
you're symbolizing a program with a single DWP file, but it's likely if
the program is dynamically linked that you might have a DWP for each
dynamic library - in which case this feature won't help (at least as
it's surfaced in llvm-symbolizer for now) - in theory it could be
extended to specify a collection of DWP files that could all be
consulted for split CU hash resolution.
llvm-svn: 309498
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: White spaces in file names are causing Phabricator/SVN to crash.
Reviewers: bkramer
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35206
llvm-svn: 307550
|
|
|
|
|
|
|
|
|
| |
This reverts commit da6318a92fba793e4f2447ec478b001392d57d43.
This is causing failures on some build bots due to what appears
to be some kind of lit ordering dependency.
llvm-svn: 306833
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Presently lit leaks files in the tests' output directories.
Specifically, if a test creates output files, lit makes no
effort to remove them prior to the next test run. This is
problematic because it leads to false positives whenever a
test passes because stale files were present. In general
it is a source of flakiness that should be removed.
This patch addresses this by building the list of all test
directories that are part of the current run set, and then
deleting those directories and recreating them anew. This
gives each test a clean baseline to start from.
Differential Revision: https://reviews.llvm.org/D34732
llvm-svn: 306832
|
|
|
|
| |
llvm-svn: 303609
|
|
|
|
|
|
|
|
|
|
|
| |
llvm-symbolizer would fail to symbolize addresses in unlinked object
files when handling .dwo file data because the addresses would not be
relocated in the same way as the ranges in the skeleton CU in the object
file.
Fix that so object files can be symbolized the same as executables.
llvm-svn: 303532
|
|
|
|
| |
llvm-svn: 303482
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
file is present
Rather than relying on the gmlt-like data emitted into the .o/executable
which only contains the simple name of any inlined functions, use the
.dwo file if present.
Test symbolication with/without a .dwo, and the old test that was
testing behavior when no gmlt-like data was present. (I haven't included
a test of non-gmlt-like data + no .dwo (that would be akin to
symbolication with no debug info) but we could add one for completeness)
The test was simplified a bit to be a little clearer (unoptimized, force
inline, using a function call as the inlined entity) and regenerated
with ToT clang. For the no-gmlt-like-data case, I modified Clang back to
its old behavior temporarily & the .dwo file is identical so it is
shared between the two executables.
llvm-svn: 267227
|
|
|
|
| |
llvm-svn: 252027
|
|
|
|
| |
llvm-svn: 252020
|
|
|
|
|
|
|
| |
Now it's enough to just specify -functions=short without additionally
providing -use-symbol-table=false.
llvm-svn: 251339
|
|
|
|
| |
llvm-svn: 221269
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
references.
Summary: getSubroutineName is currently only used by llvm-symbolizer, thus add a binary test containing a cross-cu inlining example.
Reviewers: samsonov, dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5394
llvm-svn: 218245
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
producing -gmlt data
To reduce the size of -gmlt data, skip the subprograms without any
inlined subroutines. Since we've now got the ability to make these
determinations in the backend (funnily enough - we added the flag so we
wouldn't produce ranges under -gmlt, but with this change we use the
flag, but go back to producing ranges under -gmlt).
Instead, just produce CU ranges to inform the consumer which parts of
the code are described by this CU's line table. Tools could inspect the
line table directly to compute the range, but the CU ranges only seem to
be about 0.5% of object/executable size, so I'm not too worried about
teaching llvm-symbolizer that trick just yet - it's certainly a possible
piece of future work.
Update an llvm-symbolizer test just to demonstrate that this schema is
acceptable there (if it wasn't, the compiler-rt tests would catch this,
but good to have an in-llvm-tree test for llvm-symbolizer's behavior
here)
Building the clang binary with -gmlt with this patch reduces the total
size of object files by 5.1% (5.56% without ranges) without compression
and the executable by 4.37% (4.75% without ranges).
llvm-svn: 218129
|
|
|
|
|
|
|
| |
Forge a test case where llvm-symbolizer has to use external .dwo
file to produce the inlining information.
llvm-svn: 217270
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previous algorithm for constructing [Address ranges]->[Compile Units]
mapping was wrong. It somewhat relied on the assumption that address ranges
for different compile units may not overlap. It is not so.
For example, two compile units may contain the definition of the same
linkonce_odr function. These definitions will be merged at link-time,
resulting in equivalent .debug_ranges entries for both these units
Instead of sorting and merging original address ranges (from .debug_ranges
and .debug_aranges), implement a different approach: save endpoints
of all ranges, and then use a sweep-line approach to construct
the desired mapping. If we find that certain address maps to
several compilation units, we just pick any of them.
llvm-svn: 210860
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DIEs.
Turns out that DW_AT_ranges_base attribute sets the offset for
DW_AT_ranges values specified in the .dwo file, but not for DW_AT_ranges specified
in the skeleton compile unit DIE in the main executable. This is extremely confusing,
and would hopefully be fixed in DWARF-5 when it's finalized. For now this
behavior makes sense, as otherwise Fission would break DWARF consumers who
doesn't know anything about DW_AT_ranges_base.
llvm-svn: 210809
|
|
|
|
|
|
| |
for that.
llvm-svn: 209152
|
|
|
|
|
|
|
|
|
|
| |
for a given address.
Change --functions option in llvm-symbolizer tool to accept
values "none", "short" or "linkage". Update the tests and docs
accordingly.
llvm-svn: 209050
|
|
|
|
|
|
|
|
|
|
|
| |
describing it.
This is important for symbolizing executables with debug info in
unavailable .dwo files. Even if all DIE entries are missing, we can
still symbolize an address: function name can be fetched from symbol table,
and file/line info can be fetched from line table.
llvm-svn: 206665
|
|
|
|
| |
llvm-svn: 202265
|
|
|
|
|
|
| |
PR: http://llvm.org/pr18431
Review: http://llvm-reviews.chandlerc.com/D2552
llvm-svn: 199404
|
|
|
|
|
|
| |
be symbolized.
llvm-svn: 197988
|
|
|
|
| |
llvm-svn: 193711
|
|
|
|
| |
llvm-svn: 188386
|
|
|
|
|
|
|
| |
can be removed.
FIXME: Could we use llvm::sys::Path here?
llvm-svn: 185322
|
|
|
|
| |
llvm-svn: 185151
|
|
|
|
| |
llvm-svn: 185137
|
|
|
|
|
|
| |
that symbols with zero size are in fact large enough.
llvm-svn: 183213
|
|
|
|
| |
llvm-svn: 183102
|
|
|
|
|
|
| |
nested quoting schemes, and they're not important here...
llvm-svn: 179014
|
|
|
|
| |
llvm-svn: 178859
|
|
llvm-svn: 178858
|