| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 191813
|
|
|
|
| |
llvm-svn: 191637
|
|
|
|
| |
llvm-svn: 191571
|
|
|
|
| |
llvm-svn: 191408
|
|
|
|
| |
llvm-svn: 191407
|
|
|
|
| |
llvm-svn: 191401
|
|
|
|
| |
llvm-svn: 191333
|
|
|
|
|
|
| |
CR feedback from Eric Christopher
llvm-svn: 191330
|
|
|
|
| |
llvm-svn: 191329
|
|
|
|
| |
llvm-svn: 191255
|
|
|
|
| |
llvm-svn: 191244
|
|
|
|
| |
llvm-svn: 191234
|
|
|
|
|
|
| |
coming DWARFTypeUnit.
llvm-svn: 191233
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 191209
|
|
|
|
| |
llvm-svn: 191178
|
|
|
|
|
|
| |
way in r191060.
llvm-svn: 191065
|
|
|
|
| |
llvm-svn: 191062
|
|
|
|
|
|
|
|
|
|
| |
Ensures that the pubnames entries actually refer to the intended
entities. This test could be more flexible if there was a way to do
multiline FileCheck matches with captures (in that way the test wouldn't
need to have hardcoded offset values and would thus be resilient to
changes in the layout of the DIEs in this CU).
llvm-svn: 191055
|
|
|
|
| |
llvm-svn: 191050
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a part of D1164. DWARFCompileUnit is not that lightweight
to copy it around, and we want it to own corresponding .dwo compile unit
eventually.
Reviewers: echristo
Reviewed By: echristo
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1298
llvm-svn: 189089
|
|
|
|
|
|
| |
entries. No functionality change.
llvm-svn: 187792
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
In ELF (as in MachO), not all relocations point to symbols. Represent this
properly by using a symbol_iterator instead of a SymbolRef. Update llvm-readobj
ELF's dumper to handle relocatios without symbols.
llvm-svn: 183284
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For COFF and MachO, sections semantically have relocations that apply to them.
That is not the case on ELF.
In relocatable objects (.o), a section with relocations in ELF has offsets to
another section where the relocations should be applied.
In dynamic objects and executables, relocations don't have an offset, they have
a virtual address. The section sh_info may or may not point to another section,
but that is not actually used for resolving the relocations.
This patch exposes that in the ObjectFile API. It has the following advantages:
* Most (all?) clients can handle this more efficiently. They will normally walk
all relocations, so doing an effort to iterate in a particular order doesn't
save time.
* llvm-readobj now prints relocations in the same way the native readelf does.
* probably most important, relocations that don't point to any section are now
visible. This is the case of relocations in the rela.dyn section. See the
updated relocation-executable.test for example.
llvm-svn: 182908
|
|
|
|
| |
llvm-svn: 181248
|
|
|
|
| |
llvm-svn: 181247
|
|
|
|
| |
llvm-svn: 181224
|
|
|
|
|
|
|
|
|
|
| |
getRelocationAddress is for dynamic libraries and executables,
getRelocationOffset for relocatable objects.
Mark the getRelocationAddress of COFF and MachO as not implemented yet. Add a
test of ELF's. llvm-readobj -r now prints the same values as readelf -r.
llvm-svn: 180259
|
|
|
|
|
|
|
| |
This makes llvm-dwarfdump and llvm-symbolizer understand
debug info sections compressed by ld.gold linker.
llvm-svn: 180088
|
|
|
|
| |
llvm-svn: 179682
|
|
|
|
| |
llvm-svn: 174976
|
|
|
|
| |
llvm-svn: 174463
|
|
|
|
|
|
| |
function allows a caller to obtain a table of line information for a function using the function's address and size.
llvm-svn: 173537
|
|
|
|
|
|
| |
and, in the case of ELF files, using symbol addresses when available for relocations to the .debug_info section. Also extending the llvm-rtdyld tool to add the ability to dump line number information for testing purposes.
llvm-svn: 173517
|
|
|
|
|
|
|
| |
Flags for dumping specific DWARF sections added in lib/DebugInfo and
llvm-dwarfdump.
llvm-svn: 173480
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
using the DW_FORM_GNU_addr_index and a separate .debug_addr section which
stays in the executable and is fully linked.
Sneak in two other small changes:
a) Print out the debug_str_offsets.dwo section.
b) Change form we're expecting the entries in the debug_str_offsets.dwo
section to take from ULEB128 to U32.
Add tests for all of this in the fission-cu.ll test.
llvm-svn: 172578
|
|
|
|
|
|
| |
test/DebugInfo/member-pointers.ll would not fail in targetting BE any more.
llvm-svn: 171943
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
proposal. This leaves the strings in the skeleton die as strp,
but in all dwo files they're accessed now via DW_FORM_GNU_str_index.
Add support for dumping these sections and modify the fission-cu.ll
testcase to have the correct strings and form. Fix a small bug
in the fixed form sizes routine that involved out of array accesses
for the table and add a FIXME in the extractFast routine to fix
this up.
llvm-svn: 171779
|
|
|
|
|
|
|
|
|
|
|
|
| |
sections for debug info. These are some of the dwo sections from the
DWARF5 split debug info proposal. Update the fission-cu.ll testcase
to show what we should be able to dump more of now.
Work in progress: Ultimately the relocations will be gone for the
dwo section and the strings will be a different form (as well as
the rest of the sections will be included).
llvm-svn: 171428
|
|
|
|
|
|
|
| |
Now that we don't merge section and segment names, we don't need to skip the
segment name to get to the section name.
llvm-svn: 170839
|
|
|
|
| |
llvm-svn: 168666
|
|
|
|
|
|
| |
is present: it is often the case that .debug_aranges section contains ranges only for a small subset of compile units. Test cases will be added in separate commits.
llvm-svn: 168144
|
|
|
|
| |
llvm-svn: 167757
|
|
|
|
| |
llvm-svn: 166077
|
|
|
|
| |
llvm-svn: 166076
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
code and allow better code reuse. Make the code a bit more conforming
to LLVM code style.
No functionality change.
llvm-svn: 162895
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and "instruction address -> file/line" lookup.
Instead of plain collection of rows, debug line table for compilation unit is now
treated as the number of row ranges, describing sequences (series of contiguous machine
instructions). The sequences are not always listed in the order of increasing
address, so previously used std::lower_bound() sometimes produced wrong results.
Now the instruction address lookup consists of two stages: finding the correct
sequence, and searching for address in range of rows for this sequence.
llvm-svn: 161414
|
|
|
|
|
|
|
|
| |
(instead of basenames) from DWARF. Use this behavior in llvm-dwarfdump tool.
Reviewed by Benjamin Kramer.
llvm-svn: 160496
|