[llvm-dev] [RFC] Generate Debug Information for Labels in Function

Thu Feb 7 01:47:18 PST 2019

Well, I haven’t seen that GCC is emitting more than one DW_TAG_label per label either. So maybe clang is on the same “level” now (or I haven’t triggered that kind of optimization where you get several DW_TAG_label when using GCC).

Maybe setting breakpoints on labels aren’t supposed to be that safe when using -O1 and higher (you aren’t guaranteed that you get a break every time execution passes the label).
Or we should try to emit multiple DW_TAG_labels with the same name to see what happens.

This is not that important to me, just something I discovered when trying out the new feature. I thought that perhaps this was well known and in the category “not done yet / work still ongoing”.

/Björn

From: David Blaikie <dblaikie at gmail.com>
Sent: den 30 januari 2019 19:40
To: Björn Pettersson A <bjorn.a.pettersson at ericsson.com>
Cc: Adrian Prantl <aprantl at apple.com>; llvm-dev <hsiangkai at gmail.com>; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] [RFC] Generate Debug Information for Labels in Function

What does GCC do in situations like this?

I suspect the rightiest thing to do is probably multiple DW_TAG_labels with the same name, if that's what's happened.

I guess another question/possibility - what happens if some inline asm references the label? I guess it probably constrains the optimizer not to unroll? Maybe? If the label can be duplicated and inline asm can still correctly reference the label, maybe that's the answer - describe the label the same way inline asm "sees" it.

On Wed, Jan 30, 2019 at 6:04 AM Björn Pettersson A via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
As far as I can see we now get DW_TAG_label on trunk. Nice!

I also see that there has been some talk about loop unrolling etc. when
discussing this RFC. Was there a consensus on what should happen if we
end up with multiple dbg.label intrinsics for the same label due to
code duplication?

Here is an example where we get two "#DEBUG_LABEL: main:foo" but only one
DW_TAG_label for "foo": https://godbolt.org/z/oTpHQp

Maybe that is as expected, or is it allowed to have multiple DW_TAG_label
for the same label name?

/Björn

> -----Original Message-----
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org>> On Behalf Of Adrian
> Prantl via llvm-dev
> Sent: den 30 mars 2018 18:40
> To: Adrian Prantl <aprantl at apple.com<mailto:aprantl at apple.com>>
> Cc: llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
> Subject: Re: [llvm-dev] [RFC] Generate Debug Information for Labels in
> Function
>
>
>
> > On Mar 30, 2018, at 9:25 AM, Adrian Prantl via llvm-dev <llvm-
> dev at lists.llvm.org<mailto:dev at lists.llvm.org>> wrote:
> >
> >
> >
> >> On Mar 29, 2018, at 11:29 PM, Hsiangkai Wang <hsiangkai at gmail.com<mailto:hsiangkai at gmail.com>>
> wrote:
> >>
> >> I agree with you. Attach debug metadata to basic block will be a
> >> better solution. I will change my design to convey debug metadata
> >> through basic block instead of intrinsic.
> >>
> >> https://reviews.llvm.org/D45078
> >
> > In this revised design it is now possible to attach a DILabel to a
> BasicBlock. When the basic block is inlined it will be ambiguous to
> which function the DILabel belongs. For instructions, we store the
> inline information in the inlinedAt: field of its DILocation. In order
> to handle inlining for DILabels we have two options:
> >
> >  1. Also attach a DILocation to be associated with the label to carry
> the inline information, and teach the inliner to correctly update the
> DILocation on basic blocks during inlining. This would also solve the
> issue of hypothetical scoped labels that Paul brought up. We'll also
> need to figure out what to do when two labels are being merged by a
> transformation.
> >
> >  2. Teach the inliner to drop all metadata attachments on basic
> blocks.
> >
> > Option (2) is obviously going to be easier to implement and might be
> a good as a first step.
>
> I'm really sorry for not realizing this yesterday, but the problems
> pertaining to inlining made me realize that your original design with
> the dbg.label intrinsic might actually be a better approach especially
> when considering optimized code. We will get inlining support for free
> because it is just another instruction and it can deal with more than
> one label at the same address. It looks a bit more complicated in
> unoptimized code, but that seems like a small price to pay.
>
> We just need to make sure that the backend doesn't get confused when
> loop unrolling duplicates a dbg.label but that should be doable.
>
> -- adrian
>
> >
> >>
> >>> That said, perhaps this isn't even necessary. The only information
> that is stored in DILabel is the name of the label (which is redundant
> with the actual name of the label) and its source location, which is
> also stored in the DILocation (!11). I'm wondering if the DILocation of
> a label is even useful. When a debugger user sets a breakpoint of a
> label, we might as well use the location of the first instruction in
> the basic block described by the label, since that is where execution
> will continue.
> >>>
> >>> Based on that I think it might be sufficient to have a flag on an
> IR label that marks a user-originated label and triggers the backend to
> create a DW_TAG_label for it. If we do need source location information
> for the DW_TAG_label, we could grab it from the first instruction.
> >> I still think that we should collect debug information from source
> >> code level instead of infer from instructions in the basic block. As
> >> Paul said, "the top instructions in a block do not necessarily have
> a
> >> valid source location." So, I will keep DILabel metadata and remove
> >> llvm.dbg.label intrinsic.
> >
> > I'm still not convinced that this information will be useful to a
> debugger, but if you have a compelling use-case please let me know.
> >
> > -- adrian
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://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/20190207/da83659b/attachment-0001.html>