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

> On Mar 29, 2018, at 10:55 AM, paul.robinson at sony.com wrote:
> 
> 
> 
>> -----Original Message-----
>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
via
>> llvm-dev
>> Sent: Thursday, March 29, 2018 1:54 PM
>> To: aprantl at apple.com; hsiangkai at gmail.com
>> Cc: llvm-dev at lists.llvm.org
>> Subject: Re: [llvm-dev] [RFC] Generate Debug Information for Labels in
>> Function
>> 
>>> 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.
>> 
>> Are there languages where labels are scoped?  If so we'd need
explicit
>> metadata to identify the parent scope.  In C/C++ the only scope is the
>> containing function, which I'm guessing we wouldn't need to
specify
>> (except for inlined functions? that might need some care to get right).
>> 
>> I feel compelled to point out that the top instructions in a block do
not
>> necessarily have a valid source location so we might want to carry that
>> explicitly just for sanity's sake.
> 
> That is, carry the source location explicitly on the label.
Thanks that's a good point. I still wonder what a debugger would do with the
source location of a label though? For setting breakpoints it seems redundant
with the location of the next instruction. Does GCC emit source location for a
label, or just its name? If yes, does GDB do anything with that information?

-- adrian

> -----Original Message-----
> From: aprantl at apple.com [mailto:aprantl at apple.com]
> Sent: Thursday, March 29, 2018 2:23 PM
> To: Robinson, Paul
> Cc: hsiangkai at gmail.com; llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] [RFC] Generate Debug Information for Labels in
> Function
> 
> 
> 
> > On Mar 29, 2018, at 10:55 AM, paul.robinson at sony.com wrote:
> >
> >
> >
> >> -----Original Message-----
> >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On
Behalf Of
> via
> >> llvm-dev
> >> Sent: Thursday, March 29, 2018 1:54 PM
> >> To: aprantl at apple.com; hsiangkai at gmail.com
> >> Cc: llvm-dev at lists.llvm.org
> >> Subject: Re: [llvm-dev] [RFC] Generate Debug Information for
Labels in
> >> Function
> >>
> >>> 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.
> >>
> >> Are there languages where labels are scoped?  If so we'd need
explicit
> >> metadata to identify the parent scope.  In C/C++ the only scope is
the
> >> containing function, which I'm guessing we wouldn't need
to specify
> >> (except for inlined functions? that might need some care to get
right).
> >>
> >> I feel compelled to point out that the top instructions in a block
do
> not
> >> necessarily have a valid source location so we might want to carry
that
> >> explicitly just for sanity's sake.
> >
> > That is, carry the source location explicitly on the label.
> 
> Thanks that's a good point. I still wonder what a debugger would do
with
> the source location of a label though? For setting breakpoints it seems
> redundant with the location of the next instruction. Does GCC emit source
> location for a label, or just its name? If yes, does GDB do anything with
> that information?
> 
> -- adrian
A GUI debugger might show the source text near the label definition.
Suppose the first code after the label is an inlined function call.
Using the instruction's location would take you to the source for the
inlined function, not to the label and the source for the call.
--paulr

> On Mar 29, 2018, at 11:51 AM, paul.robinson at sony.com wrote:
> 
> 
> 
>> -----Original Message-----
>> From: aprantl at apple.com [mailto:aprantl at apple.com]
>> Sent: Thursday, March 29, 2018 2:23 PM
>> To: Robinson, Paul
>> Cc: hsiangkai at gmail.com; llvm-dev at lists.llvm.org
>> Subject: Re: [llvm-dev] [RFC] Generate Debug Information for Labels in
>> Function
>> 
>> 
>> 
>>> On Mar 29, 2018, at 10:55 AM, paul.robinson at sony.com wrote:
>>> 
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On
Behalf Of
>> via
>>>> llvm-dev
>>>> Sent: Thursday, March 29, 2018 1:54 PM
>>>> To: aprantl at apple.com; hsiangkai at gmail.com
>>>> Cc: llvm-dev at lists.llvm.org
>>>> Subject: Re: [llvm-dev] [RFC] Generate Debug Information for
Labels in
>>>> Function
>>>> 
>>>>> 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.
>>>> 
>>>> Are there languages where labels are scoped?  If so we'd
need explicit
>>>> metadata to identify the parent scope.  In C/C++ the only scope
is the
>>>> containing function, which I'm guessing we wouldn't
need to specify
>>>> (except for inlined functions? that might need some care to get
right).
>>>> 
>>>> I feel compelled to point out that the top instructions in a
block do
>> not
>>>> necessarily have a valid source location so we might want to
carry that
>>>> explicitly just for sanity's sake.
>>> 
>>> That is, carry the source location explicitly on the label.
>> 
>> Thanks that's a good point. I still wonder what a debugger would do
with
>> the source location of a label though? For setting breakpoints it seems
>> redundant with the location of the next instruction. Does GCC emit
source
>> location for a label, or just its name? If yes, does GDB do anything
with
>> that information?
>> 
>> -- adrian
> 
> A GUI debugger might show the source text near the label definition.
> Suppose the first code after the label is an inlined function call.
> Using the instruction's location would take you to the source for the
> inlined function, not to the label and the source for the call.
Yes, but LLDB at least only looks at .debug_line to determine the source to
display for a given PC. This is quite annoying at -O0 with always_inline
constructors in libcxx.

A label immediately followed by an inlined instruction will be invisible to the
.debug_line table. It would also be ambiguous whether the label is part of a
(lexical, inlined) scope in the .debug_info section if it appears at the
beginning that scope.

-- adrian