thr3ads.net - llvm dev - [llvm-dev] [RFC] Generate Debug Information for Labels in Function [Feb 2019]

If this information is useful, please help other people find it:
Share via:

David Blaikie via llvm-dev

2019-Jan-30 18:39 UTC

[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> 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> On Behalf Of
Adrian
> > Prantl via llvm-dev
> > Sent: den 30 mars 2018 18:40
> > To: Adrian Prantl <aprantl at apple.com>
> > Cc: llvm-dev <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> wrote:
> > >
> > >
> > >
> > >> On Mar 29, 2018, at 11:29 PM, Hsiangkai Wang <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
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > 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
> 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/20190130/2cf60540/attachment.html>

Björn Pettersson A via llvm-dev

2019-Feb-07 09:47 UTC

head link

[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/da83659b/attachment-0001.html>

via llvm-dev

2019-Feb-07 16:50 UTC

head link

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

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>

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

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

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

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