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

What happened with this? Is there something for review in Phabricator? Or was
this put-on-hold/forgotten?

I also have some users that complain that some gdb test suite tests don't
work with LLVM due to missing debug info regarding ending brace.
So gettint the location for the "endLine" field of DISubprogram etc
should at least be a step in the right direction,
and if someone already has a fix for that it sounds interesting.

/Björn
> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
> bluechristlove via llvm-dev
> Sent: den 3 augusti 2017 19:24
> To: Simon Cook <simon.cook at embecosm.com>; llvm-dev <llvm-
> dev at lists.llvm.org>
> Subject: Re: [llvm-dev] Why LLVM doesn't have debug information of
> function right parentheses？
> 
> Simon, I also think of the way you did. :-) And from my initial
investigation,
> clang should also has some work(i.e. provide the end location for the
> "endLine" field of DISubprogram), right?
> 
> BTW, Simon, your fork of LLVM is open source or not? If open source, could
> you give the address of it?
> 
> Thanks
> 
> 
> < Simon Cook via llvm-dev <mailto:llvm-dev at lists.llvm.org> >
在 2017-08-04
> 00:10:59 写道:
> 
> 
> 
> 
> 	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
> 	_______________________________________________
> 	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
>

I added one attribute named EndLine in LLVM IR before. LLVM's part is not
hard, but will modify many places in Clang. I success for it, you can try this
way.


At 2018-04-12 16:53:21, "Björn Pettersson A" <bjorn.a.pettersson at
ericsson.com> wrote:
>What happened with this? Is there something for review in Phabricator? Or
was this put-on-hold/forgotten?
>
>I also have some users that complain that some gdb test suite tests
don't work with LLVM due to missing debug info regarding ending brace.
>So gettint the location for the "endLine" field of DISubprogram
etc should at least be a step in the right direction,
>and if someone already has a fix for that it sounds interesting.
>
>/Björn
>
>> -----Original Message-----
>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
>> bluechristlove via llvm-dev
>> Sent: den 3 augusti 2017 19:24
>> To: Simon Cook <simon.cook at embecosm.com>; llvm-dev <llvm-
>> dev at lists.llvm.org>
>> Subject: Re: [llvm-dev] Why LLVM doesn't have debug information of
>> function right parentheses？
>> 
>> Simon, I also think of the way you did. :-) And from my initial
investigation,
>> clang should also has some work(i.e. provide the end location for the
>> "endLine" field of DISubprogram), right?
>> 
>> BTW, Simon, your fork of LLVM is open source or not? If open source,
could
>> you give the address of it?
>> 
>> Thanks
>> 
>> 
>> < Simon Cook via llvm-dev <mailto:llvm-dev at lists.llvm.org>
> 在 2017-08-04
>> 00:10:59 写道:
>> 
>> 
>> 
>> 
>> 	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
>> 	_______________________________________________
>> 	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
>> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180412/7caa2d1a/attachment.html>

Hi,

On 12/04/2018 15:35, Frozen via llvm-dev wrote:
> I added one attribute named EndLine in LLVM IR before. LLVM's part is 
> not hard, but will modify many places in Clang. I success for it, you 
> can try this way.
> 
For loops, we use a range to keep track of the start and end of the loop 
for remarks: http://llvm.org/doxygen/classllvm_1_1Loop_1_1LocRange.html

Maybe it would make sense to use something similar for function start 
and end locations?

Cheers,
Florian