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

Thu Feb 7 08:50:33 PST 2019

I think it's more like "nobody brought it up before" rather than intentional.

Emitting multiple copies of the DW_TAG_label… might confuse debuggers, especially as they'll all have the same name. But we don't want to muck with the name to discriminate the instances. I don't have an answer here, unless we want words in the DWARF spec that say "you might see multiple labels with the same name in the same scope when…"

The situation feels vaguely like when a function is inlined multiple places and might also have an out-of-line instance. "Break on foo" might only catch the out-of-line instance, which if it's never called, is not a great debugging experience either.
--paulr

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Björn Pettersson A via llvm-dev
Sent: Thursday, February 07, 2019 4:47 AM
To: David Blaikie
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] [RFC] Generate Debug Information for Labels in Function

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/60ea3d6c/attachment.html>