llvm dev - Aug 2010 - [LLVMdev] [cfe-dev] Debug information on multiple files

I've also been looking at debugging with ELF and noticed the same problem as
Renato. I just sent a patch to llvmcommits that fixes the problem.
DW_at_stmt_list needs to emit a label(and therefore a relocation) for the
offset rather a constant 0, then the linker can fixup the offset as it
shuffles object files around.

Krister


On Thu, Aug 26, 2010 at 5:11 AM, Renato Golin <rengolin at
systemcall.org>wrote:
> On 25 August 2010 18:54, Devang Patel <devang.patel at gmail.com>
wrote:
> > See "DwarfDebug problem with line section" thread on
llvmdev. Bottom
> line,
> > we may need a target specific patch for targets that do not follow
dwarf
> > standard (as per my reading) in this particular case.
>
> Hi Devang,
>
> Ok, got the background, but will reply on this email.
>
> As far as I understood, there is nothing wrong with the way clang
> deals with stmt_list. The encoding is correct (AFAIK) and the offsets
> are always zero in every object file, as there is only one line table
> and one debug_info. The problem is during link time. GCC also
> generated zero for stmt_list in the objects but links correctly in the
> end.
>
> I still haven't figured out which type of relocation is needed. All I
> know is that GCC generates .rel.debug_info relocations that clang
> doesn't:
>
> clang:
>
> ** Section #6 '.rel.debug_info' (SHT_REL)
>    Size   : 40 bytes (alignment 4)
>    Symbol table #22 '.symtab'
>    5 relocations applied to section #5 '.debug_info'
>
> GCC:
>
> ** Section #7 '.rel.debug_info' (SHT_REL)
>    Size   : 184 bytes (alignment 4)
>    Symbol table #22 '.symtab'
>    23 relocations applied to section #6 '.debug_info'
>
> I'll dig deeper and see if I can spot what should be done.
>
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100826/e26cd77a/attachment.html>

On 26 Aug 2010, at 10:32, Krister Wombell wrote:
> I've also been looking at debugging with ELF and noticed the same  
> problem as
> Renato. I just sent a patch to llvmcommits that fixes the problem.
> DW_at_stmt_list needs to emit a label(and therefore a relocation)  
> for the
> offset rather a constant 0, then the linker can fixup the offset as it
> shuffles object files around.
It's not just DW_at_stmt_list, you have to do the same for the pointer  
to the abbreviation section.


Jonas

If it's the offset in the DI header then I'm pretty sure that's
already
taken care of.

Krister


On Thu, Aug 26, 2010 at 4:59 PM, Jonas Maebe <jonas.maebe at
elis.ugent.be>wrote:
>
> On 26 Aug 2010, at 10:32, Krister Wombell wrote:
>
>  I've also been looking at debugging with ELF and noticed the same
problem
>> as
>> Renato. I just sent a patch to llvmcommits that fixes the problem.
>> DW_at_stmt_list needs to emit a label(and therefore a relocation) for
the
>> offset rather a constant 0, then the linker can fixup the offset as it
>> shuffles object files around.
>>
>
> It's not just DW_at_stmt_list, you have to do the same for the pointer
to
> the abbreviation section.
>
>
> Jonas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100827/93598062/attachment.html>

On 26 August 2010 09:32, Krister Wombell <kuwerty at gmail.com>
wrote:
> I've also been looking at debugging with ELF and noticed the same
problem as
> Renato. I just sent a patch to llvmcommits that fixes the problem.
> DW_at_stmt_list needs to emit a label(and therefore a relocation) for the
> offset rather a constant 0, then the linker can fixup the offset as it
> shuffles object files around.
Hi Krister,

We've applied your patch locally and it solved our problem, thanks!

Can somebody review/commit that before 2.8 is branched?

cheers,
--renato

Ok. I will review.

Devang

On Aug 31, 2010, at 2:15 AM, Renato Golin <rengolin at systemcall.org>
wrote:
> On 26 August 2010 09:32, Krister Wombell <kuwerty at gmail.com>
wrote:
>> I've also been looking at debugging with ELF and noticed the same
problem as
>> Renato. I just sent a patch to llvmcommits that fixes the problem.
>> DW_at_stmt_list needs to emit a label(and therefore a relocation) for
the
>> offset rather a constant 0, then the linker can fixup the offset as it
>> shuffles object files around.
> 
> Hi Krister,
> 
> We've applied your patch locally and it solved our problem, thanks!
> 
> Can somebody review/commit that before 2.8 is branched?
> 
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Aug 31, 2010, at 2:15 AM, Renato Golin wrote:
> On 26 August 2010 09:32, Krister Wombell <kuwerty at gmail.com>
wrote:
>> I've also been looking at debugging with ELF and noticed the same
problem as
>> Renato. I just sent a patch to llvmcommits that fixes the problem.
>> DW_at_stmt_list needs to emit a label(and therefore a relocation) for
the
>> offset rather a constant 0, then the linker can fixup the offset as it
>> shuffles object files around.
> 
> Hi Krister,
> 
> We've applied your patch locally and it solved our problem, thanks!
... but, as it was discussed earlier, it breaks Darwin. 
I applied a patch to handle DW_AT_stmt_list using target  hook (based on
original patch by Artur Pietrek). r112678. Please try it and let me know if it
works. If it works, please prepare a patch for debug_range using similar target
hook approach.

-
Devang