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

[Björn Pettersson A via llvm-dev]

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
>