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

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

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> 在 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
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/20170804/d9ad8ec5/attachment.html>

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
>