[llvm-dev] Tracking parts of expanded values in optimized debug

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Thu Feb 2 08:18:35 PST 2017

Debug info for optimized code is not well supported in LLVM - there's lots
that's not done/could be done to improve it.

I know Adrian's been looking at optimized code debug info for a bit
recently & not sure if this particular situation is on his radar or not.

On Thu, Feb 2, 2017 at 5:16 AM Ed Jones via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi all,
> I'm currently working on an out-of-tree backend and am trying to
> improve the debug experience when debugging optimized code. Our
> backend only has 8-bit and 16-bit legal types, so any larger values
> are expanded. The behavior I am currently seeing is that the expanded
> halves of an illegal type lose their debug information. Is this the
> expected behavior?
> For example, if I have an ISD::DBG_VALUE SDNode associated with a
> value, and that value is split up (for example a i64 load expanded
> into two i32 loads), I would expect to see a new ISD::DBG_VALUE
> tracking each fragment of the input original debug variable. However,
> I can't see anywhere this is handled. There seems to be some support
> for this, through the DW_OP_LLVM_fragment DIExpression, and there is a
> function DIBuilder::createFragmentExpression which could be used to
> create an expression to track part of a variable, however these don't
> seem to be used much.
> Thanks,
> Ed
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170202/123fbcf6/attachment-0001.html>

More information about the llvm-dev mailing list