[llvm] r289961 - Revert "dwarfdump: Support/process relocations on a CU's abbrev_off"

Tue Dec 20 14:05:49 PST 2016

On Tue, Dec 20, 2016 at 12:24 PM George Rimar <grimar at accesssoftek.com>
wrote:

> 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.
>

The way I debugged this was to break on the line in the 'if' that my patch
adds. It shows that it's adding 132 or something when run inside lld, but 0
when run in dwarfdump on the object file itself.

It looks very much like the relocation section provided to the
DWARFContextInMemory in lld has adjustments applied already - it doesn't
appear to be the same set of relocations as when reading the object file
directly in llvm-dwarfdump.

This is why there are no CUs - they fail to parse because the abbreviations
section can't be found at that offset in the input object file (I believe
that's the offset in the output instead).

Rui: Does any of this sound familiar? Are relocations in input object
memory buffers modified at some point?

>
> 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> 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
> 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/54f8f6fe/attachment.html>