| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
const from some other StringRefs since its implicitly const already.
llvm-svn: 216820
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries
(like Archive) and we had to create dummy buffers just to handle that. It is
also a bad fit for IRObjectFile where the Module wants to own the buffer too.
Keeping this ownership would make supporting IR inside native objects
particularly painful.
This patch focuses in lib/Object. If something elsewhere used to own an Binary,
now it also owns a MemoryBuffer.
This patch introduces a few new types.
* MemoryBufferRef. This is just a pair of StringRefs for the data and name.
This is to MemoryBuffer as StringRef is to std::string.
* OwningBinary. A combination of Binary and a MemoryBuffer. This is needed
for convenience functions that take a filename and return both the
buffer and the Binary using that buffer.
The C api now uses OwningBinary to avoid any change in semantics. I will start
a new thread to see if we want to change it and how.
llvm-svn: 216002
|
|
|
|
|
|
|
|
|
| |
Instead of moving out the data in a ErrorOr<std::unique_ptr<Foo>>, get
a reference to it.
Thanks to David Blaikie for the suggestion.
llvm-svn: 214516
|
|
|
|
|
|
| |
This makes using a std::unique_ptr in the caller more convenient.
llvm-svn: 214433
|
|
|
|
| |
llvm-svn: 214377
|
|
|
|
| |
llvm-svn: 212405
|
|
|
|
|
|
|
|
| |
This makes the buffer ownership on error conditions very natural. The buffer
is only moved out of the argument if an object is constructed that now
owns the buffer.
llvm-svn: 211546
|
|
|
|
| |
llvm-svn: 210876
|
|
|
|
|
|
| |
This should make sure that most new uses use the std prefix.
llvm-svn: 210835
|
|
|
|
|
|
|
| |
This is a minimal change to remove the header. I will remove the occurrences
of "using std::error_code" in a followup patch.
llvm-svn: 210803
|
|
|
|
|
|
| |
for that.
llvm-svn: 209152
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 208921
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 206654
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 204697
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 203083
|
|
|
|
| |
llvm-svn: 202957
|
|
|
|
|
|
| |
units under fission.
llvm-svn: 202091
|
|
|
|
| |
llvm-svn: 199776
|
|
|
|
| |
llvm-svn: 198850
|
|
|
|
| |
llvm-svn: 196908
|
|
|
|
|
|
| |
-debug-dump
llvm-svn: 195063
|
|
|
|
|
|
| |
Argument spelling feedback welcome.
llvm-svn: 191409
|
|
|
|
| |
llvm-svn: 191408
|
|
|
|
|
|
|
|
|
| |
This is a basic implementation - we still don't have any support (that I
know of) for dumping DWARF expressions in a meaningful way, so the
location information itself is just printed as a sequence of bytes as we
do elsewhere.
llvm-svn: 184361
|
|
|
|
| |
llvm-svn: 174976
|
|
|
|
| |
llvm-svn: 174463
|
|
|
|
|
|
|
|
|
| |
politely report it instead of running into llvm_unreachable.
Also patch llvm-dwarfdump to actually check whether the file it's attempting to
dump is a valid object file.
llvm-svn: 173489
|
|
|
|
|
|
|
| |
Flags for dumping specific DWARF sections added in lib/DebugInfo and
llvm-dwarfdump.
llvm-svn: 173480
|
|
|
|
| |
llvm-svn: 173460
|
|
|
|
|
|
|
|
| |
Again, tools are trickier to pick the main module header for than
library source files. I've started to follow the pattern of using
LLVMContext.h when it is included as a stub for program source files.
llvm-svn: 169252
|
|
|
|
| |
llvm-svn: 167757
|
|
|
|
|
|
| |
DIContext. This is needed to prevent crashes because of dangling reference if the clients don't provide RelocMap to DIContext constructor.
llvm-svn: 167728
|
|
|
|
|
|
|
| |
values in a map that can be passed to consumers. Add a testcase that
ensures this works for llvm-dwarfdump.
llvm-svn: 167558
|
|
|
|
| |
llvm-svn: 166075
|
|
|
|
|
|
|
|
|
|
|
| |
by instruction address from DWARF.
Add --inlining flag to llvm-dwarfdump to demonstrate and test this functionality,
so that "llvm-dwarfdump --inlining --address=0x..." now works much like
"addr2line -i 0x...", provided that the binary has debug info
(Clang's -gline-tables-only *is* enough).
llvm-svn: 163128
|
|
|
|
|
|
|
|
|
|
|
| |
This section (introduced in DWARF-3) is used to define instruction address
ranges for functions that are not contiguous and can't be described
by low_pc/high_pc attributes (this is the usual case for inlined subroutines).
The patch is the first step to support fetching complete inlining info from DWARF.
Reviewed by Benjamin Kramer.
llvm-svn: 162657
|
|
|
|
|
|
|
|
| |
(instead of basenames) from DWARF. Use this behavior in llvm-dwarfdump tool.
Reviewed by Benjamin Kramer.
llvm-svn: 160496
|
|
|
|
|
|
|
|
|
|
| |
parser:
1) DIContext is now able to return function name for a given instruction address (besides file/line info).
2) llvm-dwarfdump accepts flag --functions that prints the function name (if address is specified by --address flag).
3) test case that checks the basic functionality of llvm-dwarfdump added
llvm-svn: 159512
|
|
|
|
| |
llvm-svn: 146409
|
|
|
|
| |
llvm-svn: 144417
|
|
|
|
|
|
| |
new all-targets pseudo-component.
llvm-svn: 142401
|
|
|
|
| |
llvm-svn: 141392
|
|
|
|
|
|
|
|
| |
Usage:
$ llvm-dwarfdump -address=0x0000000100000ed4 a.out.dSYM/Contents/Resources/DWARF/a.out
xxx.c:6:0
llvm-svn: 139850
|
|
|
|
| |
llvm-svn: 139799
|
|
|
|
|
|
| |
The llvm-dwarfdump output isn't very verbose yet.
llvm-svn: 139771
|
|
|
|
|
|
|
|
|
|
| |
doesn't accidentaly picks up the wrong section.
Also add some validation code to the aranges section parser.
Fixes PR10926.
llvm-svn: 139701
|
|
|
|
|
|
|
|
|
| |
up to llvm-dwarfdump.
This is only one half of it, the part that caches address ranges from the DIEs when .debug_aranges is
not available will be ported soon.
llvm-svn: 139680
|
|
This introduces a new library to LLVM: libDebugInfo. It will provide debug information
parsing to LLVM. Much of the design and some of the code is taken from the LLDB project.
It also contains an llvm-dwarfdump tool that can dump the abbrevs and DIEs from an
object file. It can be used to write tests for DWARF input and output easily.
llvm-svn: 139627
|