llvm dev - Aug 2017 - Why LLVM doesn't have debug information of function right parentheses？

I have implemented this exact behavior in an out of tree LLVM fork I
maintain, where one of my users needed this behavior, and it seems to
work well. What we have done is extend the definition of DISubprogram to
contain a new field "endLine" which holds the line number of the
closing
brace. A pass late in our backend uses this information to set the
DebugLoc of return instructions in our programs.

I haven't yet tidied up and submitted this upstream for review, as
without a consumer of this information, the extension itself is rather
dead, but could if some backends would find that information useful and
make use of it.

Thanks,
Simon

On 03/08/17 15:13, Robinson, Paul via llvm-dev wrote:
> I've had this request from my users as well, but it has never been high
> enough on the priority list to look at closely.
> 
> I think it would be feasible to have the actual ret instruction
> associated with the closing brace, while the load/computation of the
> return value would be associated with the `return` statement; but
that's
> as far as I got when I looked at this before.
> 
> --paulr
> 
>  
> 
> P.S. The word "parenthesis" plural "parentheses" refers
specifically to
> these characters: ( )
> 
> Generally [ ] are "square brackets" or sometimes just
"brackets" while {
> } are called "braces" or "curly brackets."
> 
>  
> 
> *From:*llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of
> *Frozen via llvm-dev
> *Sent:* Wednesday, August 02, 2017 11:19 PM
> *To:* llvm-dev at lists.llvm.org
> *Subject:* [llvm-dev] Why LLVM doesn't have debug information of
> function right parentheses？
> 
>  
> 
> Simple Case:
> 
> 1.int main()
> 2.{
> 3.   int i = 0;
> 4.   return 0;
> 5.}
> 
> compile command: clang -g a.c
> 
> In LLVM IR, we have one attribute named "scopeLine" to indicate
the left
> parentheses. But we don't have one attribute to indicate the right
> parentheses (line 5 in this example).
> 
> So if we use gdb to debug it:
> (gdb) b main
> Breakpoint 1 at 0x100005c8: file a.c, line 3.
> (gdb) r
> Breakpoint 1, main () at a.c:3
> 3      int i = 0;
> Missing separate debuginfos,
> (gdb) n
> 4      return 0;
> (gdb) n
> 0x00003fffb7db4580 in generic_start_main.isra.0
> We can not stop at line 5.
> 
> But GCC can stop at line 5
> (gdb) b main
> Breakpoint 1 at 0x100005e0: file a.c, line 3.
> (gdb) r
> Breakpoint 1, main () at a.c:3
> 3      int i = 0;
> Missing separate debuginfos
> (gdb) n
> 4      return 0;
> (gdb) n
> 5    }
> (gdb)
> 
>  
> 
>  
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
Simon
> Cook via llvm-dev
> Sent: Thursday, August 03, 2017 11:06 AM
> To: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] Why LLVM doesn't have debug information of
> function right parentheses？
> 
> 
> I have implemented this exact behavior in an out of tree LLVM fork I
> maintain, where one of my users needed this behavior, and it seems to
> work well. What we have done is extend the definition of DISubprogram to
> contain a new field "endLine" which holds the line number of the
closing
> brace. A pass late in our backend uses this information to set the
> DebugLoc of return instructions in our programs.
Interesting.  I'd have thought the front end could generate the
return-value expression with the source location of the expression,
and the return instruction itself with source location of the closing
brace.  Then it would automatically apply to all targets (and all
debug-info formats).

Or, if that distinction got lost during some optimization, the
separate source location could be attached during instruction
selection?  Hopefully that could also be done in a target-neutral
way.
--paulr
> 
> I haven't yet tidied up and submitted this upstream for review, as
> without a consumer of this information, the extension itself is rather
> dead, but could if some backends would find that information useful and
> make use of it.
> 
> Thanks,
> Simon
> 
> On 03/08/17 15:13, Robinson, Paul via llvm-dev wrote:
> > I've had this request from my users as well, but it has never been
high
> > enough on the priority list to look at closely.
> >
> > I think it would be feasible to have the actual ret instruction
> > associated with the closing brace, while the load/computation of the
> > return value would be associated with the `return` statement; but
that's
> > as far as I got when I looked at this before.
> >
> > --paulr
> >
> >
> >
> > P.S. The word "parenthesis" plural "parentheses"
refers specifically to
> > these characters: ( )
> >
> > Generally [ ] are "square brackets" or sometimes just
"brackets" while {
> > } are called "braces" or "curly brackets."
> >
> >
> >
> > *From:*llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf
Of
> > *Frozen via llvm-dev
> > *Sent:* Wednesday, August 02, 2017 11:19 PM
> > *To:* llvm-dev at lists.llvm.org
> > *Subject:* [llvm-dev] Why LLVM doesn't have debug information of
> > function right parentheses？
> >
> >
> >
> > Simple Case:
> >
> > 1.int main()
> > 2.{
> > 3.   int i = 0;
> > 4.   return 0;
> > 5.}
> >
> > compile command: clang -g a.c
> >
> > In LLVM IR, we have one attribute named "scopeLine" to
indicate the left
> > parentheses. But we don't have one attribute to indicate the right
> > parentheses (line 5 in this example).
> >
> > So if we use gdb to debug it:
> > (gdb) b main
> > Breakpoint 1 at 0x100005c8: file a.c, line 3.
> > (gdb) r
> > Breakpoint 1, main () at a.c:3
> > 3      int i = 0;
> > Missing separate debuginfos,
> > (gdb) n
> > 4      return 0;
> > (gdb) n
> > 0x00003fffb7db4580 in generic_start_main.isra.0
> > We can not stop at line 5.
> >
> > But GCC can stop at line 5
> > (gdb) b main
> > Breakpoint 1 at 0x100005e0: file a.c, line 3.
> > (gdb) r
> > Breakpoint 1, main () at a.c:3
> > 3      int i = 0;
> > Missing separate debuginfos
> > (gdb) n
> > 4      return 0;
> > (gdb) n
> > 5    }
> > (gdb)
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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

On 03/08/17 16:21, Robinson, Paul via llvm-dev wrote:
> 
>>
>> I have implemented this exact behavior in an out of tree LLVM fork I
>> maintain, where one of my users needed this behavior, and it seems to
>> work well. What we have done is extend the definition of DISubprogram
to
>> contain a new field "endLine" which holds the line number of
the closing
>> brace. A pass late in our backend uses this information to set the
>> DebugLoc of return instructions in our programs.
> 
> Interesting.  I'd have thought the front end could generate the
> return-value expression with the source location of the expression,
> and the return instruction itself with source location of the closing
> brace.  Then it would automatically apply to all targets (and all
> debug-info formats).
This works in most cases. It feels the cleaner solution for its
target-independence, and was the first way that I tried to solve this
problem. It works, apart from the most trivial of functions.

The case I'm thinking of is a function that just returns a constant, we
only have one instruction to attach a source location to, and ideally
would like to associate the lowering of the return value with one
location, and the actual return with the other. This is what caused me
to switch from a return instruction associated location, to something
that I unconditionally set later on in my backend. I suppose the same
could occur during some optimizations, and we would still want to
recover the location.
> 
> Or, if that distinction got lost during some optimization, the
> separate source location could be attached during instruction
> selection?  Hopefully that could also be done in a target-neutral
> way.
Aah, good idea. Having this as part of instruction selection/return
lowering sounds like a more appropriate place to set the location
generically if it needs resetting, as it should be safe from thereon in.

Thanks,
Simon

I should also point out the clang does generate instructions associated with
closing curly braces for calls to destructors of stack-allocated C++ objects.
Check out test/CodeGenCXX/linetable-cleanup.cpp for examples of this behavior.

-- adrian
> On Aug 3, 2017, at 8:21 AM, Robinson, Paul via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
Simon
>> Cook via llvm-dev
>> Sent: Thursday, August 03, 2017 11:06 AM
>> To: llvm-dev at lists.llvm.org
>> Subject: Re: [llvm-dev] Why LLVM doesn't have debug information of
>> function right parentheses？
>> 
>> 
>> I have implemented this exact behavior in an out of tree LLVM fork I
>> maintain, where one of my users needed this behavior, and it seems to
>> work well. What we have done is extend the definition of DISubprogram
to
>> contain a new field "endLine" which holds the line number of
the closing
>> brace. A pass late in our backend uses this information to set the
>> DebugLoc of return instructions in our programs.
> 
> Interesting.  I'd have thought the front end could generate the
> return-value expression with the source location of the expression,
> and the return instruction itself with source location of the closing
> brace.  Then it would automatically apply to all targets (and all
> debug-info formats).
> 
> Or, if that distinction got lost during some optimization, the
> separate source location could be attached during instruction
> selection?  Hopefully that could also be done in a target-neutral
> way.
> --paulr
> 
>> 
>> I haven't yet tidied up and submitted this upstream for review, as
>> without a consumer of this information, the extension itself is rather
>> dead, but could if some backends would find that information useful and
>> make use of it.
>> 
>> Thanks,
>> Simon
>> 
>> On 03/08/17 15:13, Robinson, Paul via llvm-dev wrote:
>>> I've had this request from my users as well, but it has never
been high
>>> enough on the priority list to look at closely.
>>> 
>>> I think it would be feasible to have the actual ret instruction
>>> associated with the closing brace, while the load/computation of
the
>>> return value would be associated with the `return` statement; but
that's
>>> as far as I got when I looked at this before.
>>> 
>>> --paulr
>>> 
>>> 
>>> 
>>> P.S. The word "parenthesis" plural
"parentheses" refers specifically to
>>> these characters: ( )
>>> 
>>> Generally [ ] are "square brackets" or sometimes just
"brackets" while {
>>> } are called "braces" or "curly brackets."
>>> 
>>> 
>>> 
>>> *From:*llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On
Behalf Of
>>> *Frozen via llvm-dev
>>> *Sent:* Wednesday, August 02, 2017 11:19 PM
>>> *To:* llvm-dev at lists.llvm.org
>>> *Subject:* [llvm-dev] Why LLVM doesn't have debug information
of
>>> function right parentheses？
>>> 
>>> 
>>> 
>>> Simple Case:
>>> 
>>> 1.int main()
>>> 2.{
>>> 3.   int i = 0;
>>> 4.   return 0;
>>> 5.}
>>> 
>>> compile command: clang -g a.c
>>> 
>>> In LLVM IR, we have one attribute named "scopeLine" to
indicate the left
>>> parentheses. But we don't have one attribute to indicate the
right
>>> parentheses (line 5 in this example).
>>> 
>>> So if we use gdb to debug it:
>>> (gdb) b main
>>> Breakpoint 1 at 0x100005c8: file a.c, line 3.
>>> (gdb) r
>>> Breakpoint 1, main () at a.c:3
>>> 3      int i = 0;
>>> Missing separate debuginfos,
>>> (gdb) n
>>> 4      return 0;
>>> (gdb) n
>>> 0x00003fffb7db4580 in generic_start_main.isra.0
>>> We can not stop at line 5.
>>> 
>>> But GCC can stop at line 5
>>> (gdb) b main
>>> Breakpoint 1 at 0x100005e0: file a.c, line 3.
>>> (gdb) r
>>> Breakpoint 1, main () at a.c:3
>>> 3      int i = 0;
>>> Missing separate debuginfos
>>> (gdb) n
>>> 4      return 0;
>>> (gdb) n
>>> 5    }
>>> (gdb)
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev