string_ostream is a safe and efficient string builder that combines opaque
stack storage with a built-in ostream interface.
small_string_ostream<bytes> additionally permits an explicit stack storage size
other than the default 128 bytes to be provided. Beyond that, storage is
transferred to the heap.
This convenient class can be used in most places an
std::string+raw_string_ostream pair or SmallString<>+raw_svector_ostream pair
would previously have been used, in order to guarantee consistent access
without byte truncation.
The patch also converts much of LLVM to use the new facility. These changes
include several probable bug fixes for truncated output, a programming error
that's no longer possible with the new interface.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211749 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210860 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210809 91177308-0d34-0410-b5e6-96231b3b80d8
Change --functions option in llvm-symbolizer tool to accept
values "none", "short" or "linkage". Update the tests and docs
accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209050 91177308-0d34-0410-b5e6-96231b3b80d8
It is more appropriate than the current situation, when one flag
(AbsoluteFilePath) is relevant only if another flag is set.
This refactoring would also simplify fetching the short function name
(stored in DW_AT_name) instead of a linkage name returned currently.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208921 91177308-0d34-0410-b5e6-96231b3b80d8
Streamline parsing and dumping line tables:
Prefer composition to multiple inheritance in DWARFDebugLine::ParsingState.
Get rid of the weird concept of "DumpingState" structure.
was:
DWARFDebugLine::DumpingState state(OS);
DWARFDebugLine::parseStatementTable(..., state);
now:
DWARFDebugLine::LineTable LineTable;
LineTable.parse(...);
LineTable.dump(OS);
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207599 91177308-0d34-0410-b5e6-96231b3b80d8
Move several function definitions into .cpp, unify constructors
and clear() methods (fixing a couple of latent bugs from copy-paste),
turn static function parsePrologue() into Prologue::parse().
More work needed here to untangle weird multiple inheritance
in table parsing and dumping.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207579 91177308-0d34-0410-b5e6-96231b3b80d8
DIE doesn't need to store a pointer to its parent: we can traverse the DIE tree
only with functions getFirstChild() and getSibling(). Parents must be known
only when we construct the tree. Rewrite setDIERelations() procedure in a more
straightforward way, and get rid of lots of now unused DIEMinimal methods.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207563 91177308-0d34-0410-b5e6-96231b3b80d8
FrameEntry doesn't need to hold a reference to the section it is
located in. Instead, pass DataExtractor as an argument of parsing
function.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207461 91177308-0d34-0410-b5e6-96231b3b80d8
There is no need to keep the whole contents of .debug_aranges section
in memory when we build address ranges table. Memory optimization that
used to be in this code (precalculate the size of vector of ranges before
filling it) is not really needed - later we will compact and resize this
vector anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207457 91177308-0d34-0410-b5e6-96231b3b80d8
behavior based on other files defining DEBUG_TYPE, which means it cannot
define DEBUG_TYPE at all. This is actually better IMO as it forces folks
to define relevant DEBUG_TYPEs for their files. However, it requires all
files that currently use DEBUG(...) to define a DEBUG_TYPE if they don't
already. I've updated all such files in LLVM and will do the same for
other upstream projects.
This still leaves one important change in how LLVM uses the DEBUG_TYPE
macro going forward: we need to only define the macro *after* header
files have been #include-ed. Previously, this wasn't possible because
Debug.h required the macro to be pre-defined. This commit removes that.
By defining DEBUG_TYPE after the includes two things are fixed:
- Header files that need to provide a DEBUG_TYPE for some inline code
can do so by defining the macro before their inline code and undef-ing
it afterward so the macro does not escape.
- We no longer have rampant ODR violations due to including headers with
different DEBUG_TYPE definitions. This may be mostly an academic
violation today, but with modules these types of violations are easy
to check for and potentially very relevant.
Where necessary to suppor headers with DEBUG_TYPE, I have moved the
definitions below the includes in this commit. I plan to move the rest
of the DEBUG_TYPE macros in LLVM in subsequent commits; this one is big
enough.
The comments in Debug.h, which were hilariously out of date already,
have been updated to reflect the recommended practice going forward.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206822 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206665 91177308-0d34-0410-b5e6-96231b3b80d8
Immutable DILineInfo doesn't bring any benefits and complicates
code. Also, use std::string instead of SmallString<16> for file
and function names - their length can vary significantly.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206654 91177308-0d34-0410-b5e6-96231b3b80d8
When address ranges for compile unit are specified in compile unit DIE
itself, there is no need to collect ranges from children subprogram DIEs.
This change speeds up llvm-symbolizer on Clang-produced binaries with
full debug info. For instance, symbolizing a first address in a 1Gb binary
is now 2x faster (1s vs. 2s).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206641 91177308-0d34-0410-b5e6-96231b3b80d8
Add a helper method to get address ranges specified in a DIE
(either by DW_AT_low_pc/DW_AT_high_pc, or by DW_AT_ranges). Use it
to untangle and simplify the code.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206624 91177308-0d34-0410-b5e6-96231b3b80d8
This avoids an extra copy during decompression and avoids the use of
MemoryBuffer which is a weirdly esoteric device that includes unrelated
concepts like "file name" (its rather generic name is a bit misleading).
Similar refactoring of zlib::compress coming up.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205676 91177308-0d34-0410-b5e6-96231b3b80d8
Implement debug_loc.dwo, as well as llvm-dwarfdump support for dumping
this section.
Outlined in the DWARF5 spec and http://gcc.gnu.org/wiki/DebugFission the
debug_loc.dwo section has more variation than the standard debug_loc,
allowing 3 different forms of entry (plus the end of list entry). GCC
seems to, and Clang certainly, only use one form, so I've just
implemented dumping support for that for now.
It wasn't immediately obvious that there was a good refactoring to share
the implementation of dumping support between debug_loc and
debug_loc.dwo, so they're separate for now - ideas welcome or I may come
back to it at some point.
As per a comment in the code, we could choose different forms that may
reduce the number of debug_addr entries we emit, but that will require
further study.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204697 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This adds ObjectFile::section_iterator_range, that allows to write
range-based for-loops running over all sections of a given file.
Several files from lib/ are converted to the new interface. Similar fixes
should be applied to a variety of llvm-* tools.
Reviewers: rafael
Reviewed By: rafael
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3069
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203799 91177308-0d34-0410-b5e6-96231b3b80d8
This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203083 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This adds support for emitting DWARF path discriminator values in
the object streamer. It also changes the DWARF dumper to show
discriminator values in the line table output.
Reviewers: echristo
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2794
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201427 91177308-0d34-0410-b5e6-96231b3b80d8
sections. The call to data.getUnsigned(&Offset, AddressSize) only
increments Offset if the read succeeds, which will result in an infinite
loop.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201179 91177308-0d34-0410-b5e6-96231b3b80d8
None of the object file formats reported error on iterator increment. In
retrospect, that is not too surprising: no object format stores symbols or
sections in a linked list or other structure that requires chasing pointers.
As a consequence, all error checking can be done on begin() and end().
This reduces the text segment of bin/llvm-readobj in my machine from 521233 to
518526 bytes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200442 91177308-0d34-0410-b5e6-96231b3b80d8
This makes it easier to write a test that's mostly shared between
fission and non-fission (using FileCheck's multiple prefix support).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198806 91177308-0d34-0410-b5e6-96231b3b80d8
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.
Also comment and sink the include of "Windows.h" in three .inc files to
match the usage in Memory.inc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198685 91177308-0d34-0410-b5e6-96231b3b80d8
This commit does not complete the type units feature - there are issues
around fission support (skeletal type units, pubtypes/pubnames) and
hashing of some types including those containing references to types in
other type units.
Originally committed as r197073 and reverted in r197079.
Recommitted as r197197 to reproduce the failure and reverted as r197199
Turns out there was unstable ordering in the type unit dumping code.
Fixed by using MapVector in DWARFContext to store the debug_types
comdat sections.
Recommitted as r197210 with a fix to dumping and reverted as r197211
because I was a bit gun shy and thought I saw a failure that turned out
to be unrelated.
So here we go - once more with feeling! \o/
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197275 91177308-0d34-0410-b5e6-96231b3b80d8
This commit does not complete the type units feature - there are issues
around fission support (skeletal type units, pubtypes/pubnames) and
hashing of some types including those containing references to types in
other type units.
Originally committed as r197073 and reverted in r197079.
Recommitted as r197197 to reproduce the failure and reverted as r197199
Turns out there was unstable ordering in the type unit dumping code.
Fixed by using MapVector in DWARFContext to store the debug_types
comdat sections.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197210 91177308-0d34-0410-b5e6-96231b3b80d8
In a failed attempt to allow the gnu-public-names.ll test case to not
hardcode the size of the unit that the pubnames section referred to I've
at least managed to have unit headers and pubnames headers print out in
a similar style.
This failed to achieve the desired goal because the header in a unit
specifies the length of the unit without the length element of the
header whereas the length in the pubnames includes this element, so the
numbers are off by 4 bytes. I don't know of any arithmetic powers in
FileCheck so the test case can't simply say "CU_LENGTH + 4".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193872 91177308-0d34-0410-b5e6-96231b3b80d8
MSVC can't comprehend
template<typename T, size_t N>
ArrayRef<T> makeArrayRef(const T (&Arr)[N]) {
return ArrayRef<T>(Arr);
}
if Arr is
static const uint8_t sizes[];
declared in a templated and defined a few lines later.
I'll send a proper fix (i.e. get rid of unnecessary templates) for review soon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193604 91177308-0d34-0410-b5e6-96231b3b80d8
Complicated CU-DIE-specific logic in the latter was never used,
and it makes sense to have safety checks for broken dwarf in the former.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193563 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Use DWARF4 table of form classes to fetch attributes from DIE
in a more consistent way. This shouldn't change the functionality and
serves as a refactoring for upcoming change: DW_AT_high_pc has different
semantics depending on its form class.
Reviewers: dblaikie, echristo
Reviewed By: echristo
CC: echristo, llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1961
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193553 91177308-0d34-0410-b5e6-96231b3b80d8
Parsing .debug_aranges section now takes O(nlogn) operations instead
of O(n^2), where "n" is the number of address ranges. With this change,
the time required to symbolize an address from a random large
Clang-generated binary drops from 165 seconds to 1.5 seconds.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191781 91177308-0d34-0410-b5e6-96231b3b80d8
This is a small step that may enable some simplifications in producer
(DWARFContext) and consumer (DWARFCompileUnit and other places) by
making a more complete abstraction around the data and relocations for a
section. Small initial steps could include simple changes such as
passing the pair to DWARFCompileUnit's ctor rather than passing the data
and relocs separately. I don't intend to pursue any such changes
immediately, however.
The motivation for doing this now is that type unit dumping will need to
deal with these data+reloc pairs moreso than the existing dumping
support has needed to associate the data as type unit sections are named
the same (debug_types) and comdat group folded. So to implement dumping
and reloc handling we'll need a mapping of section->data+relocs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191209 91177308-0d34-0410-b5e6-96231b3b80d8
