[PATCH] D33655: [Cloning] Take another pass at properly cloning debug info

[David Blaikie via llvm-commits]

On Tue, May 30, 2017 at 12:15 PM Gor Nishanov <gornishanov at gmail.com> wrote:

> I am thinking as llvm gets more sophisticated outlining facilities where
> parts of function could be extracted into separate functions to help with
> inlining, vectorization, openmp, exceptions, etc, coroutines won't remain
> unique. From the debugging experience, it is still the original function,
> just split up into more than one for some only optimizer known reason :)
>

Sure - bit more complicated than that, though (I mean any function cloning
is). As I was talking with Richard about this the other day, some thoughts:

If the user asks to break on the function - does that break on all of the
coroutine fragments? (ie: every time you enter the function, not just when
you enter at the start of the function)
What's the function name in a backtrace, if you're in a fragment of the
function - if it's just the plain function name might that be confusing to
users, since there's no call to the function from the caller, exactly? (I
mean there's lots of implicit operations in C++, so maybe that's not
totally bad)

& presumably calls to the function (or taking its address, etc) in a
debugger expression evaluator should only find the original function, not
the fragments...

(& the more complicated part: getting the variable locations right -
that'll take some more work going through the dynamically allocated frame
block, etc)


>
> On Tue, May 30, 2017 at 10:46 AM, David Blaikie <dblaikie at gmail.com>
> wrote:
>
>>
>>
>> On Tue, May 30, 2017 at 8:17 AM Adrian Prantl via Phabricator <
>> reviews at reviews.llvm.org> wrote:
>>
>>> aprantl accepted this revision.
>>> aprantl added a comment.
>>> This revision is now accepted and ready to land.
>>>
>>> Thanks Keno, this appears to be a far better approach. The only question
>>> that remains is whether / how to update the linkage name of the cloned
>>> DISubprogram. But I don't think that this needs to be solved in this patch.
>>>
>>
>> *nod* Agreed.
>>
>> Speculating rampantly: I wonder if it'd make sense to remove the linkage
>> name from definitions and use the actual Function's linkage name (hmm, that
>> doesn't work for inlining, though - so maybe it does have to be duplicated
>> when the function is cloned - but could then have a verifier/invariant that
>> it matches the Function if there is one). And then even allow the mangled
>> name to differ between declaration and definition - and put an extra
>> DW_AT_linkage_name on the definition if it's different from the declaration.
>>
>> *shrug* Don't really know. The right answers may require thinking a fair
>> bit about the coroutines debug info as a (perhaps somewhat unique) example
>> of cloning, etc.
>>
>>
>>>
>>>
>>> https://reviews.llvm.org/D33655
>>>
>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170530/17e52b92/attachment.html>