[LLVMdev] [cfe-dev] Debug information on multiple files

[Krister Wombell]

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>