[PATCH] D11180: Fixed debug info generation for function static variables, typedef, and records

[David Blaikie via llvm-commits]

On Thu, Aug 27, 2015 at 4:03 PM, Amjad Aboud via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> aaboud added a comment.
>
> In http://reviews.llvm.org/D11180#234335, @dblaikie wrote:
>
> > It'd be good to split this up as much as possible - it'll make review &
> commit history easier, etc.
> >
> > Could you create a separate review just for the "don't omit declarations
> for unused (fully inlined and optimized away) functions" part that we
> discussed & you've included here?
>
>
> Yes, it will make sense to commit the " don't emit declarations for unused
> (fully inlined and optimized away) functions" separately, but before the
> other changes.
> I will move this part out of this review and open a new one asap.
>

Thanks!


>
> > After that I think, if I recall our conversation correctly, it might be
> handy to look at delaying the adding of static variables and local types
> until the end of the module - and put them in the abstract origin when
> there is one (rather than always putting them in the concrete definition -
> and losing them if there is no concrete definition? (that's the current
> behavior, yes?)).
>
>
> As you agreed, now the local DIEs (i.e. local static variable and local
> types) are created without being attached to a context and only in at
> "endModule()" function we call the "finishLexicalBlockDefinitions()" that
> will attach these DIEs either to the abstract lexical block (if available),
> or to the concrete lexical block.
>

Right, what I'm suggesting is that part could be done separately from the
scope handling stuff.

This change would ensure that the DIEs go in the right function (the
abstract one or the concrete one) - which would fix bugs that occur when
there is no concrete DIE, if I understand correctly?

For example, currently if you have a static local variable in a function
that is inlined we produce an abstract definition, an inlined subroutine,
but then we also produce this weird stub-concrete definition (a subprogram
tag with /only/ an abstract_origin attribute, and the child DW_TAG_variable
for the static variable). If we delay the addition of the local types and
static variables and just put them in the abstract definition if there is
one, we shouldn't end up producing the weird stub concrete definition
(that's not really a concrete definition anyway).

So that would be a good, separable, incremental step. /then/ we can have a
separate (3rd) patch or patches to try to put it in the right scopes?


>
> > Then after that, look at trying to keep track of the right scopes, the
> minimal scopes, etc?
>
>
> The minimal scope is guaranteed as we still create lexical block the same
> way we did before, so there is no empty lexical block created.
> However, you might see empty lexical block in the inline function, but
> that is only because in the equivalent lexical block in the abstract
> function there is a DIE.
> After committing this patch, we might want to add a DIE to the inline
> lexical block with the "abstract_origin" attribute pointing to the DIE in
> the abstract lexical block.
>
> Please, read the new summary, I tried to explain the current
> design/implementation plus what we might want to do as next step.
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D11180
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150827/47bdea75/attachment.html>