This reverts commit rL358161.
This patch have broken the test:
llvm/test/tools/llvm-exegesis/X86/uops-CMOV16rm-noreg.s
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358199 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Make DW_LNS_copy set the discriminator register to 0, to conform to
DWARF 4 & 5: "Then it sets the discriminator register to 0, and sets the
basic_block, prologue_end and epilogue_begin registers to false."
Because all of DW_LNE_end_sequence, DN_LNS_copy, and special opcodes reset
discriminator to 0, we can move discriminator=0 to appendRowToMatrix.
Also, make DW_LNS_copy print before appending the row, as it is similar
to a address+=0,line+=0 special opcode, which prints before appending
the row.
Reviewers: dblaikie, probinson, aprantl
Reviewed By: dblaikie
Subscribers: danielcdh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60364
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358148 91177308-0d34-0410-b5e6-96231b3b80d8
We want the last row whose address is less than or equal to Address.
This can be computed as upper_bound - 1, which is simpler than
lower_bound followed by skipping equal rows in a loop.
Since FirstRow (LowPC) does not satisfy the predicate (OrderByAddress)
while LastRow-1 (HighPC) satisfies the predicate. We can decrease the
search range by two, i.e.
upper_bound [FirstRow,LastRow) = upper_bound [FirstRow+1,LastRow-1)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358053 91177308-0d34-0410-b5e6-96231b3b80d8
In a sorted list of non-overlapping [LowPC,HighPC) ranges, locating an address with
upper_bound on HighPC is simpler than lower_bound on LowPC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358012 91177308-0d34-0410-b5e6-96231b3b80d8
The current lower_bound approach has to check two iterators pos and pos-1.
Changing it to upper_bound allows us to check one iterator (similar to
DWARFUnitVector::getUnitFor*).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@357834 91177308-0d34-0410-b5e6-96231b3b80d8
In general, llvm-symbolizer follows the output style of GNU's addr2line.
However, there are still some differences; in particular, for a requested
address, llvm-symbolizer prints line and column, while addr2line prints
only the line number.
This patch adds a new switch to select the preferred style.
Differential Revision: https://reviews.llvm.org/D60190
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@357675 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Now CVType and CVSymbol are effectively type-safe wrappers around
ArrayRef<uint8_t>. Make the kind() accessor load it from the
RecordPrefix, which is the same for types and symbols.
Reviewers: zturner, aganea
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60018
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@357658 91177308-0d34-0410-b5e6-96231b3b80d8
The standard doesn't require a DW_TAG_variable, DW_TAG_formal_parameter
or DW_TAG_constant to A DW_AT_type attribute describing the type of the
variable. It only specifies that it *can* have one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@357628 91177308-0d34-0410-b5e6-96231b3b80d8
This avoids allocating a few KB of heap memory on startup, and instead
allocates these maps lazily. I noticed this while profiling LLD.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@357192 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit rL357020.
The commit broke the test llvm/test/tools/llvm-objdump/embedded-source.test
on some builds including clang-ppc64be-linux-multistage,
clang-s390x-linux, clang-with-lto-ubuntu, clang-x64-windows-msvc,
llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast (and others).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@357026 91177308-0d34-0410-b5e6-96231b3b80d8
Reapply rL356941 after regenerating the object file in the failing test
llvm/test/tools/llvm-objdump/embedded-source.test from source.
Original commit message:
[llvm] Prevent duplicate files in debug line header in dwarf 5.
Motivation: In previous dwarf versions, file name indexes started from 1, and
the primary source file was not explicit. Dwarf 5 standard (6.2.4) prescribes
the primary source file to be explicitly given an entry with an index number 0.
The current implementation honors the specification by just duplicating the
main source file, once with index number 0, and later maybe with another
index number. While this is compliant with the letter of the standard, the
duplication causes problems for consumers of this information such as lldb.
(Some files are duplicated, where only some of them have a line table although
all refer to the same file)
With this change, dwarf 5 debug line section files always start from 0, and
the zeroth entry is not duplicated whenever possible. This requires different
handling of dwarf 4 and dwarf 5 during generation (e.g. when a function returns
an index zero for a file name, it signals an error in dwarf 4, but not in dwarf 5)
However, I think the minor complication is worth it, because it enables all
consumers (lldb, gdb, dwarfdump, objdump, and so on) to treat all files in the
file name list homogenously.
Tags: #llvm, #debug-info
Differential Revision: https://reviews.llvm.org/D59515
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@357018 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 312ab05887d0e2caa29aaf843cefe39379a98d36.
My commit broke the build; I will revert and find out what happened.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356951 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Motivation: In previous dwarf versions, file name indexes started from 1, and
the primary source file was not explicit. Dwarf 5 standard (6.2.4) prescribes
the primary source file to be explicitly given an entry with an index number 0.
The current implementation honors the specification by just duplicating the
main source file, once with index number 0, and later maybe with another
index number. While this is compliant with the letter of the standard, the
duplication causes problems for consumers of this information such as lldb.
(Some files are duplicated, where only some of them have a line table although
all refer to the same file)
With this change, dwarf 5 debug line section files always start from 0, and
the zeroth entry is not duplicated whenever possible. This requires different
handling of dwarf 4 and dwarf 5 during generation (e.g. when a function returns
an index zero for a file name, it signals an error in dwarf 4, but not in dwarf 5)
However, I think the minor complication is worth it, because it enables all
consumers (lldb, gdb, dwarfdump, objdump, and so on) to treat all files in the
file name list homogenously.
Reviewers: dblaikie, probinson, aprantl, espindola
Reviewed By: probinson
Subscribers: emaste, jvesely, nhaehnle, aprantl, javed.absar, arichardson, hiraditya, MaskRay, rupprecht, jdoerfert, llvm-commits
Tags: #llvm, #debug-info
Differential Revision: https://reviews.llvm.org/D59515
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356941 91177308-0d34-0410-b5e6-96231b3b80d8
[Symbolizer] Add getModuleSectionIndexForAddress() helper routine
The https://reviews.llvm.org/D58194 patch changed symbolizer interface.
Particularily it requires not only Address but SectionIndex also.
Note object::SectionedAddress parameter:
Expected<DILineInfo> symbolizeCode(const std::string &ModuleName,
object::SectionedAddress ModuleOffset,
StringRef DWPName = "");
There are callers of symbolizer which do not know particular section index.
That patch creates getModuleSectionIndexForAddress() routine which
will detect section index for the specified address. Thus if caller
set ModuleOffset.SectionIndex into object::SectionedAddress::UndefSection
state then symbolizer would detect section index using
getModuleSectionIndexForAddress routine.
Differential Revision: https://reviews.llvm.org/D58848
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356829 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
getRelocatedValue may compute incorrect value for SHT_RELA-typed relocation entries.
// DWARFDataExtractor.cpp
uint64_t DWARFDataExtractor::getRelocatedValue(uint32_t Size, uint32_t *Off,
...
// This formula is correct for REL, but may be incorrect for RELA if the value
// stored in the location (getUnsigned(Off, Size)) is not zero.
return getUnsigned(Off, Size) + Rel->Value;
In this patch, we
* refactor these visit* functions to include a new parameter `uint64_t A`.
Since these visit* functions are no longer used as visitors, rename them to resolve*.
+ REL: A is used as the addend. A is the value stored in the location where the
relocation applies: getUnsigned(Off, Size)
+ RELA: The addend encoded in RelocationRef is used, e.g. getELFAddend(R)
* and add another set of supports* functions to check if a given relocation type is handled.
DWARFObjInMemory uses them to fail early.
Reviewers: echristo, dblaikie
Reviewed By: echristo
Subscribers: mgorny, aprantl, aheejin, fedor.sergeev, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57939
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356729 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This considers module symbol streams and the global symbol stream to be
roots. Most types that this considers "unreferenced" are referenced by
LF_UDT_MOD_SRC_LINE id records, which VC seems to always include.
Essentially, they are types that the user can only find in the debugger
if they call them by name, they cannot be found by traversing a symbol.
In practice, around 80% of type information in a PDB is referenced by a
symbol. That seems like a reasonable number.
I don't really plan to do anything with this tool. It mostly just exists
for informational purposes, and to confirm that we probably don't need
to implement type reference tracking in LLD. We can continue to merge
all types as we do today without wasting space.
Reviewers: zturner, aganea
Subscribers: mgorny, hiraditya, arphaman, jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59620
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356692 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce a DW_OP_LLVM_convert Dwarf expression pseudo op that allows
for a convenient way to perform type conversions on the Dwarf expression
stack. As an additional bonus it paves the way for using other Dwarf
v5 ops that need to reference a base_type.
The new DW_OP_LLVM_convert is used from lib/Transforms/Utils/Local.cpp
to perform sext/zext on debug values but mainly the patch is about
preparing terrain for adding other Dwarf v5 ops that need to reference a
base_type.
For Dwarf v5 the op maps to DW_OP_convert and for earlier versions a
complex shift & mask pattern is generated to emulate sext/zext.
This is a recommit of r356442 with trivial fixes for the failing tests.
Differential Revision: https://reviews.llvm.org/D56587
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356451 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce a DW_OP_LLVM_convert Dwarf expression pseudo op that allows
for a convenient way to perform type conversions on the Dwarf expression
stack. As an additional bonus it paves the way for using other Dwarf
v5 ops that need to reference a base_type.
The new DW_OP_LLVM_convert is used from lib/Transforms/Utils/Local.cpp
to perform sext/zext on debug values but mainly the patch is about
preparing terrain for adding other Dwarf v5 ops that need to reference a
base_type.
For Dwarf v5 the op maps to DW_OP_convert and for earlier versions a
complex shift & mask pattern is generated to emulate sext/zext.
Differential Revision: https://reviews.llvm.org/D56587
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356442 91177308-0d34-0410-b5e6-96231b3b80d8
Before, empty debug streams were written as 8 bytes (4 bytes signature + 4 bytes for the GlobalRefs count).
With this patch, unused empty streams aren't emitted anymore. Modules now encode 65535 as an 'unused stream' value, by convention.
Also fix the * Linker * contrib section which wasn't correctly emitted previously.
Differential Revision: https://reviews.llvm.org/D59502
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356395 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is similar to how addr2line handles consecutive entries with the
same address - pick the last one.
Reviewers: dblaikie, friss, JDevlieghere
Reviewed By: dblaikie
Subscribers: eugenis, vitalybuka, echristo, JDevlieghere, probinson, aprantl, hiraditya, rupprecht, jdoerfert, llvm-commits
Tags: #llvm, #debug-info
Differential Revision: https://reviews.llvm.org/D58952
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356265 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is similar to how addr2line handles consecutive entries with the
same address - pick the last one.
Reviewers: dblaikie, friss, JDevlieghere
Reviewed By: dblaikie
Subscribers: ormris, echristo, JDevlieghere, probinson, aprantl, hiraditya, rupprecht, jdoerfert, llvm-commits
Tags: #llvm, #debug-info
Differential Revision: https://reviews.llvm.org/D58952
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355972 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Swift now generates PDBs for debugging on Windows. llvm and lldb
need a language enumerator value too properly handle the output
emitted by swiftc.
Subscribers: jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59231
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355882 91177308-0d34-0410-b5e6-96231b3b80d8
Change the format type of *Personality and *LSDAAddress to PRIx64 since
they are of type uint64_t.
The problem was detected on mips builds, where it was printing junk values
and causing test failure.
Patch by Milos Stojanovic.
Differential Revision: https://reviews.llvm.org/D58451
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355607 91177308-0d34-0410-b5e6-96231b3b80d8
When dumping ToT clan's debug info with dwarfdump, we were seeing an
error saying that that the location list overflows the debug_loc
section. After reducing the testcase we figured out that we were
interpreting the DW_FORM_data4 as a section offset.
In DWARF3 DW_FORM_data4 and DW_FORM_data8 served also as a section
offset. Until now we didn't check check for the DWARF version, because
some producers (read old versions of clang) were still emitting this.
The relevant code/comment was added in 2013, and I believe it's now
reasonable to start checking the version.
The FormValue class is a little bit of a mess because it cashes the
DWARF unit and context when it extracted the value itself. Several
methods of the class rely on it being present, or return an Optional for
the code path that needs it. At the same time the FormValue class also
used in places where there's no DWARF unit.
For this patch I went with the least invasive change: checking the
version from the CU when it's available. If it's not (because the form
value was created from a value directly) we default to the old behavior.
Differential revision: https://reviews.llvm.org/D58698
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355456 91177308-0d34-0410-b5e6-96231b3b80d8
Continues the work started in r354941. Changes (all but one) uses of the
extractValue to static createFromData.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355233 91177308-0d34-0410-b5e6-96231b3b80d8
That patch is the fix for https://bugs.llvm.org/show_bug.cgi?id=40703
"wrong line number info for obj file compiled with -ffunction-sections"
bug. The problem happened with only .o files. If object file contains
several .text sections then line number information showed incorrectly.
The reason for this is that DwarfLineTable could not detect section which
corresponds to specified address(because address is the local to the
section). And as the result it could not select proper sequence in the
line table. The fix is to pass SectionIndex with the address. So that it
would be possible to differentiate addresses from various sections. With
this fix llvm-objdump shows correct line numbers for disassembled code.
Differential review: https://reviews.llvm.org/D58194
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354972 91177308-0d34-0410-b5e6-96231b3b80d8
DWARFFormValues can be created from a data extractor or by passing its
value directly. Until now this was done by member functions that
modified an existing object's internal state. This patch replaces a
subset of these methods with static method that return a new
DWARFFormValue.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354941 91177308-0d34-0410-b5e6-96231b3b80d8
Adds llvm-dwarfdump support for pretty printing Dwarf5 expressions ops
that reference a base type (right now only DW_OP_convert is added).
Includes verification to verify that the ops operand is actually a
DW_TAG_base_type DIE.
Differential Revision: https://reviews.llvm.org/D58442
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354552 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
llvm-symbolizer would originally report symbols that belonged to an invalid object file section.
Specifically the case where: `*Symbol.getSection() == ObjFile.section_end()`
This patch prevents the Symbolizer from collecting symbols that belong to invalid sections.
The test (from PR40591) introduces a case where two symbols have address 0,
one symbol is defined, 'foo', and the other is not defined, 'bar'. This patch will cause
the Symbolizer to keep 'foo' and ignore 'bar'.
As a side note, the logic for adding symbols to the Symbolizer's store
(`SymbolizableObjectFile::addSymbol`) replaces symbols with the
same <address, size> pair. At some point that logic should be revisited as in the
aforementioned case, 'bar' was overwriting 'foo' in the Symbolizer's store,
and 'foo' was forgotten.
This fixes PR40591
Reviewers: jhenderson, rupprecht
Reviewed By: rupprecht
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58146
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354083 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
rL189250 added a realpath call, and rL352916 because realpath breaks assumptions with some build systems. However, the /usr/lib/debug case has been clarified, falling back to /usr/lib/debug is currently broken if the obj passed in is a relative path. Adding a call to use absolute paths when falling back to /usr/lib/debug fixes that while still not making any realpath assumptions.
This also adds a --fallback-debug-path command line flag for testing (since we probably can't write to /usr/lib/debug from buildbot environments), but was also verified manually:
```
$ rm -f path/to/dwarfdump-test.elf-x86-64
$ strace llvm-symbolizer --obj=relative/path/to/dwarfdump-test.elf-x86-64.debuglink 0x40113f |& grep dwarfdump
```
Lookups went to relative/path/to/dwarfdump-test.elf-x86-64, relative/path/to/.debug/dwarfdump-test.elf-x86-64, and then finally /usr/lib/debug/absolute/path/to/dwarfdump-test.elf-x86-64.
Reviewers: dblaikie, samsonov
Reviewed By: dblaikie
Subscribers: krytarowski, aprantl, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57916
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353730 91177308-0d34-0410-b5e6-96231b3b80d8
