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

[David Blaikie]

On Sun, Jul 26, 2015 at 12:19 AM, Amjad Aboud <amjad.aboud at intel.com> wrote:

> aaboud added inline comments.
>
> ================
> Comment at: lib/CodeGen/AsmPrinter/DwarfDebug.h:239
> @@ +238,3 @@
> +  // Collection of abstract global variables.
> +  DenseMap<const MDNode *, DIE *> AbstractGlobalVariables;
> +  SmallVector<std::pair<const MDNode *, DIE *>, 32>
> ConcreteGlobalVariables;
> ----------------
> dblaikie wrote:
> > I can't quite follow it - why are these two data structures necessary
> now (but weren't necessary prior to your proposed change)?
> In my original solution I did not consider optimized code, especially
> inline functions.
> Now as I need to take care of these cases, it led us to the need for
> handling function static variables for function been inlined.


> Notice that in the today implementation, where the function static
> variable is always associated to the function regardless of the lexical
> block it is defined in, the function static variable is being defined once
> even when the function is being inlined.
>

OK, so that sounds like possibly an orthogonal bug? It'd be nice to
separate out the fix for it

It seems a bit weird to me that we'd even want the variable in the
inlined_subroutine. I'd want to see what GCC does here - but it may be
simpler to just defer that whole discussion of what, if anything, is the
right thing to do there, to a separate email thread to keep things
clear/separate?


> This means that you will not have access to that variable from the caller
> function.
>
> With this patch, I am not just solving the static lexical block issue but
> also assure have access to that static variable from the caller function.
>
> If you think that I should not bother solving this debugging issue, I
> might be able to do less changes and keep the current behavior (of losing
> debug info when inline).
>
> What do you think?
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D11180
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150727/d2bef74e/attachment.html>