llvm dev - Feb 2014 - [LLVMdev] How is variable info retrieved in debugging for executables generated by llvm backend?

On Thu, Feb 20, 2014 at 1:58 PM, Yuri <yuri at rawbw.com> wrote:
> On 02/18/2014 00:44, 杨勇勇 wrote:
>
>> I ported llvm backend and lldb recently. Both tools can basically work.
>> lldb is able to debug programs in asm style and frame unwinding is OK.
>>
>> But "frame variable XX" does not work because lldb is not
able to
>> determine
>> the address of
>> XX from debug info.
>>
>
> I recently did some work with the debug info as generated by llvm, and
> there are a lot of bugs. LLVM writes wrong DWARF info. My impression is
> that DWARF writer is barely passable with clang-generated code, or maybe it
> malfunctions with clang as well. People don't hold debug info to the
same
> high standard as the code itself.
>
> Here is an example when variable info generated is plain wrong:
> http://llvm.org/bugs/show_bug.cgi?id=18866

Certainly there are bugs, but practically speaking I wouldn't characterize
clang-generated debug info to be "barely passable". It generally works
for
me - it passes much of the GDB 7.5 test suite successfully.

(this is all predicated on: "at -O0" - optimized debug info is another
story entirely. Though there are even issues with locations (and sometimes
even types!) at -O0, but they're pretty rare in my experience - I use Clang
to debug Clang day-to-day and only every few months do I hit a bug)

>
>
> Yuri
>
>
> _______________________________________________
> 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/20140220/3c341512/attachment.html>

On 02/20/2014 14:07, David Blaikie wrote:
> Certainly there are bugs, but practically speaking I wouldn't
characterize
> clang-generated debug info to be "barely passable". It generally
works for
> me - it passes much of the GDB 7.5 test suite successfully.
Clang works, but I am getting an impression that any deviations from 
what clang does causes troubles.
I don't know, every time I look, I find something wrong with resulting 
DWARF.
>
> (this is all predicated on: "at -O0" - optimized debug info is
another
> story entirely. Though there are even issues with locations (and sometimes
> even types!) at -O0, but they're pretty rare in my experience - I use
Clang
> to debug Clang day-to-day and only every few months do I hit a bug)
Yes, my test case is for -O0 and CL=Large. Debug info for optimized code 
is a different issue, you are right.

Yuri

On Thu, Feb 20, 2014 at 2:16 PM, Yuri <yuri at rawbw.com> wrote:
> On 02/20/2014 14:07, David Blaikie wrote:
>
>> Certainly there are bugs, but practically speaking I wouldn't
characterize
>> clang-generated debug info to be "barely passable". It
generally works for
>> me - it passes much of the GDB 7.5 test suite successfully.
>>
>
> Clang works, but I am getting an impression that any deviations from what
> clang does causes troubles.
> I don't know, every time I look, I find something wrong with resulting
> DWARF.
>
>
>
>> (this is all predicated on: "at -O0" - optimized debug info
is another
>> story entirely. Though there are even issues with locations (and
sometimes
>> even types!) at -O0, but they're pretty rare in my experience - I
use
>> Clang
>> to debug Clang day-to-day and only every few months do I hit a bug)
>>
>
> Yes, my test case is for -O0 and CL=Large.

Not sure what you mean by "CL=Large". Another caveat to -O0, is
that's
Clang's style of -O0 (this is one of those "what Clang generates is
what
works best" cases): emitting allocas for each variable to keep track of the
location easily.

Also, it's not clear that Yang even has the issues you have - no mention of
a custom frontend, just a custom backend (granted no mention that Yang is
using Clang either, so it could go either way).

- David

> Debug info for optimized code is a different issue, you are right.
>
> Yuri
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140220/a1d3db79/attachment.html>