Re: [Diffusion] rL309526: DebugInfo: Use base address selection entries in debug_ranges to reduce…

[David Blaikie via llvm-commits]

Here we go, thuis should do the trick: r309529

Happy to help with more fixes, help with LLDB functionality, etc. Thanks
for the report/diagnosis!

On Sun, Jul 30, 2017 at 4:56 PM David Blaikie <dblaikie at gmail.com> wrote:

> On Sun, Jul 30, 2017 at 4:49 PM Tamas Berghammer via Phabricator <
> reviews at reviews.llvm.org> wrote:
>
>> tberghammer added subscribers: llvm-commits, tberghammer.
>> tberghammer raised a concern with this commit.
>> tberghammer added a comment.
>>
>> Hi David,
>>
>> This CL caused a regression in LLDB by generating some incorrect
>> relocations for the debug info. To reproduce:
>>
>> Compile the following source code using ToT clang (trunk 309523) for
>> x86_64-unknown-linux-gnu with "clang -g -c -o ns2.cpp ns2.o"
>>
>>   inline int a() { return 1; }
>>   void b() { a(); }
>>   void c() {}
>>
>> Running "objdump -W -r ns2.o" will show the following data:
>>
>>   Contents of the .debug_ranges section:
>>
>>       Offset   Begin    End
>>       00000000 ffffffffffffffff 0000000000000000 (base address)
>>       00000000 0000000000000000 0000000000000016
>>       00000000 0000000000000020 0000000000000026
>>       00000000 0000000000000000 000000000000000b
>>       00000000 <End of list>
>>
>>   ....
>>
>>   RELOCATION RECORDS FOR [.debug_ranges]:
>>   OFFSET           TYPE              VALUE
>>   0000000000000008 R_X86_64_64       .text
>>   0000000000000030 R_X86_64_64       .text._Z1av
>>   0000000000000038 R_X86_64_64       .text._Z1av
>>
>> Looking at the data it will apply both the base address entry and the
>> relocation entry for the 4th row in the debug_ranges section what will mean
>> they will end up with invalid values.
>>
>
> Ah, I see what you mean - the base address selection entry has to be
> reset. Makes sense. Thanks! Will get that fixed ASAP.
>
>
>>
>> Note: As far as I can tell LLDB doesn't support these base address
>> entries but that should be an easy fix on the LLDB side what I can take
>> care of once clang emits the correct data.
>>
>>
>> Users:
>>   dblaikie (Author)
>>   tberghammer (Auditor)
>>
>> https://reviews.llvm.org/rL309526
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170731/8e307926/attachment.html>