[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