This is very rudimentary support for debug_cu_index, but it is enough to
allow llvm-dwarfdump to find the offsets for contributions and
correctly dump debug_info.
It will need to actually find the real signature of the unit and build
the real hash table with the right number of buckets, as per the DWP
specification.
It will also need to be expanded to cover the tu_index as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254489 91177308-0d34-0410-b5e6-96231b3b80d8
This is a recommit of 252842 which was reverted in 252859. The issue was
using %s format specifier for a StringRef - used Format's
left_justify(StringRef, int) instead.
It'd be nice to have __attribute__((format(..))) on llvm::format, but
apparently it's only implemented for c-style variadics, not C++ variadic
templates. Perhaps we could fix that & conditionalize the attribute on
such...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253065 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
PE files are stripped by default, and only contain the names of exported
symbols.
The actual reason that we bother to do this override by default is
actually due to a quirk of the way -gline-tables-only is implemented, so
I phrased the check as "if we are symbolizing from dwarf, do the symtab
override".
This fixes lots of Windows ASan tests that I broke in r250582.
Reviewers: samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14594
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253051 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce DIPrinter which takes care of rendering DILineInfo and
friends. This allows LLVMSymbolizer class to return a structured data
instead of plain std::strings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251989 91177308-0d34-0410-b5e6-96231b3b80d8
Make printDILineInfo and friends responsible for just rendering the
contents of the structures, demangling should actually be performed
earlier, when we have the information about the originating
SymbolizableModule at hand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251981 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce LLVMSymbolizer::symbolizeInlinedCode() instead of switching
on PrintInlining option passed to the constructor. This will be needed
once we retrun structured data (instead of std::string) from
LLVMSymbolizer and move printing logic out.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251675 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is mostly NFC. It is a first step in cleaning up LLVMSymbolize
library. It removes "ModuleInfo" class which bundles together ObjectFile
and its debug info context in favor of:
* abstract SymbolizableModule in public headers;
* SymbolizableObjectFile subclass in implementation.
Additionally, SymbolizableObjectFile is now created via factory, so we
can properly detect object parsing error at this stage instead of keeping
the broken half-parsed object. As a next step, we would be able to
propagate the error all the way back to the library user.
Further improvements might include:
* factoring out the logic of finding appropriate file with debug info
for a given object file, and caching all parsed object files into a
separate class [A].
* factoring out DILineInfo rendering [B].
This would make what is now a heavyweight "LLVMSymbolizer" a relatively
straightforward class, that calls into [A] to turn filepath into a
SymbolizableModule, delegates actual symbolization to concrete SymbolizableModule
implementation, and lets [C] render the result.
Reviewers: dblaikie, echristo, rafael
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14099
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251662 91177308-0d34-0410-b5e6-96231b3b80d8
LLVMSymbolizer::Options is mostly used in LLVMSymbolizer class anyway.
Let's keep their usage restricted to that class, especially given that
it's worth to move ModuleInfo to a different header, independent from
the symbolizer class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251363 91177308-0d34-0410-b5e6-96231b3b80d8
Now it's enough to just specify -functions=short without additionally
providing -use-symbol-table=false.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251339 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Previously the relative address flag only affected PDB debug info. Now
both DIContext implementations always expect to be passed virtual
addresses. llvm-symbolizer is now responsible for adding ImageBase to
module offsets when --relative-offset is passed.
Reviewers: zturner
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12883
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249784 91177308-0d34-0410-b5e6-96231b3b80d8
Not only do we not need to do anything to read correct values from the
object files, but the current logic actually wrongly applies twice the
section base address when there is no LoadedObjectInfo passed to the
DWARFContext creation (as the added test shows).
Simply do not apply any relocations on the mach-o debug info if there is
no load offset to apply.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245807 91177308-0d34-0410-b5e6-96231b3b80d8
This function can actually fail since the symbol contains an index to the
section and that can be invalid.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@244375 91177308-0d34-0410-b5e6-96231b3b80d8
When encountering a scattered relocation, the code would assert trying to
access an unexisting section. I couldn't find a way to expose the result
of the processing of a scattered reloc, and I'm really unsure what the
right thing to do is. This patch just skips them during the processing in
DwarfContext and adds a mach-o file to the tests that exposed the asserting
behavior.
(This is a new failure that is being exposed by Rafael's recent work on
the libObject interfaces. I think the wrong behavior has always happened,
but now it's asserting)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243778 91177308-0d34-0410-b5e6-96231b3b80d8
