[llvm] r289961 - Revert "dwarfdump: Support/process relocations on a CU's abbrev_off"
George Rimar via llvm-commits
llvm-commits at lists.llvm.org
Tue Dec 20 12:24:33 PST 2016
From what I see it is would be very strange if lld change the input file content,
we use parsers in a very straightforward way:
template <class ELFT>
GdbIndexBuilder<ELFT>::GdbIndexBuilder(InputSection<ELFT> *DebugInfoSec)
: DebugInfoSec(DebugInfoSec) {
if (Expected<std::unique_ptr<object::ObjectFile>> Obj =
object::ObjectFile::createObjectFile(DebugInfoSec->getFile()->MB))
Dwarf.reset(new DWARFContextInMemory(*Obj.get(), this));
else
error(toString(DebugInfoSec->getFile()) + ": error creating DWARF context");
}
and when I compare code with/without your patch I just see that
Dwarf->compile_units() starts to return nothing, what is a reason of fail for testcase:
GdbIndexBuilder<ELFT>::readAddressArea(size_t CurrentCU) {
...
for (const auto &CU : Dwarf->compile_units()) { // <-- HERE
You wrote "Is this data somehow modified by lld rather than being the raw bytes from the input file ?",
I see no reasons for that now. But what I suggest - let me check that all tomorrow,
I'll try to debug the details.
As far I understand is what I need - is just to recheck
that we pass the same data to DWARFContextInMemory that we have in raw objects.
I would be surprised if that is not true.
Best regards,
George.
________________________________
От: George Rimar
Отправлено: 20 декабря 2016 г. 21:16
Кому: David Blaikie
Копия: Rui Ueyama; llvm-commits at lists.llvm.org
Тема: RE: [llvm] r289961 - Revert "dwarfdump: Support/process relocations on a CU's abbrev_off"
Hi David,
I'll can apply this patch and take a look on this closer
in a next hour or two and will be able to answer then.
Best regards,
George.
________________________________
От: David Blaikie <dblaikie at gmail.com>
Отправлено: 20 декабря 2016 г. 21:02
Кому: llvm-commits at lists.llvm.org; George Rimar
Копия: Rui Ueyama
Тема: Re: [llvm] r289961 - Revert "dwarfdump: Support/process relocations on a CU's abbrev_off"
Hi George,
Committing this change broke your gdb-index test in lld.
It looks like the info section had a non-zero offset in the relocation pointing to the abbrev section, but the abbrev section in the object has the data at start (& dumping the raw object file from disk shows the relocation has a zero offset)
Is this data somehow modified by lld rather than being the raw bytes from the input file? How/why/where?
Any idea how to fix this change/lld so it doesn't have this problem?
As it is, dwarfdump is crashing on inputs I care about & this change seems like a reasonable fix for it, so I'm guessing we probably want to fix lld in some way?
- Dave
On Fri, Dec 16, 2016 at 9:20 AM David Blaikie via llvm-commits <llvm-commits at lists.llvm.org<mailto:llvm-commits at lists.llvm.org>> wrote:
Author: dblaikie
Date: Fri Dec 16 11:10:17 2016
New Revision: 289961
URL: http://llvm.org/viewvc/llvm-project?rev=289961&view=rev
Log:
Revert "dwarfdump: Support/process relocations on a CU's abbrev_off"
Reverting because this breaks lld's gdb_index support - it's probably
double counting the abbrev relocation offset.
This reverts commit r289954.
Removed:
llvm/trunk/test/DebugInfo/Inputs/dwarfdump-abbrev-off.elf-x86-64
llvm/trunk/test/DebugInfo/dwarfdump-abbrev-off.test
Modified:
llvm/trunk/lib/DebugInfo/DWARF/DWARFUnit.cpp
Modified: llvm/trunk/lib/DebugInfo/DWARF/DWARFUnit.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/DebugInfo/DWARF/DWARFUnit.cpp?rev=289961&r1=289960&r2=289961&view=diff
==============================================================================
--- llvm/trunk/lib/DebugInfo/DWARF/DWARFUnit.cpp (original)
+++ llvm/trunk/lib/DebugInfo/DWARF/DWARFUnit.cpp Fri Dec 16 11:10:17 2016
@@ -87,10 +87,7 @@ bool DWARFUnit::getStringOffsetSectionIt
bool DWARFUnit::extractImpl(DataExtractor debug_info, uint32_t *offset_ptr) {
Length = debug_info.getU32(offset_ptr);
Version = debug_info.getU16(offset_ptr);
- auto AI = InfoSection.Relocs.find(*offset_ptr);
uint64_t AbbrOffset = debug_info.getU32(offset_ptr);
- if (AI != InfoSection.Relocs.end())
- AbbrOffset += AI->second.second;
if (IndexEntry) {
if (AbbrOffset)
return false;
Removed: llvm/trunk/test/DebugInfo/Inputs/dwarfdump-abbrev-off.elf-x86-64
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/DebugInfo/Inputs/dwarfdump-abbrev-off.elf-x86-64?rev=289960&view=auto
==============================================================================
Binary files llvm/trunk/test/DebugInfo/Inputs/dwarfdump-abbrev-off.elf-x86-64 (original) and llvm/trunk/test/DebugInfo/Inputs/dwarfdump-abbrev-off.elf-x86-64 (removed) differ
Removed: llvm/trunk/test/DebugInfo/dwarfdump-abbrev-off.test
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/DebugInfo/dwarfdump-abbrev-off.test?rev=289960&view=auto
==============================================================================
--- llvm/trunk/test/DebugInfo/dwarfdump-abbrev-off.test (original)
+++ llvm/trunk/test/DebugInfo/dwarfdump-abbrev-off.test (removed)
@@ -1,8 +0,0 @@
-RUN: llvm-dwarfdump -debug-dump=info %p/Inputs/dwarfdump-abbrev-off.elf-x86-64 | FileCheck %s
-
-Check that we apply relocations to the abbr_offset - while LLVM never produces
-an object file like this, a reproduction can be produced by linking two simple
-object files together with ld -r.
-
-CHECK: abbr_offset = 0x0000
-CHECK: abbr_offset = 0x0010
_______________________________________________
llvm-commits mailing list
llvm-commits at lists.llvm.org<mailto:llvm-commits at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161220/86375c88/attachment.html>
More information about the llvm-commits
mailing list