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

[Frozen via 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>