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

[Adrian Prantl via llvm-dev]

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