[PATCH] D67410: [DWARF] Emit call site parameter info when tuning for lldb

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 11 13:46:58 PDT 2019


dblaikie added a comment.

In D67410#1666856 <https://reviews.llvm.org/D67410#1666856>, @vsk wrote:

> In D67410#1666505 <https://reviews.llvm.org/D67410#1666505>, @dblaikie wrote:
>
> > In D67410#1666370 <https://reviews.llvm.org/D67410#1666370>, @aprantl wrote:
> >
> > > I'm very curious what the effect of this patch on our green dragon statistics bot will be (http://green.lab.llvm.org/green/view/LLDB/job/clang-3.4-debuginfo-statistics/).
> >
> >
> > What sort of statistics do we track that would be impacted by this change?
>
>
> None for now, because debug entry values are gated behind a CC1 flag the bot does not use.


This change is enabling them by default when tuning for LLDB, right? Or still only when using the cc1 flag /and/ tuning for LLDB?

Oh, I see - this is about whether to use the GNU forms or the DWARFv5 forms, not whether to enable the feature by default - I get it now.

>   I'm not sure what the plan is here exactly, but what I'd like to do is turn this on by default for DWARF5, and leave the CC1 flag for anyone who wants call site information in DWARF4 mode.
>    
> 
>> (to me it doesn't seem like this feature would improve coverage, etc - partly mechanically (this adds new tags we might not have any stats for)
> 
> (assuming we're compiling for DWARF5 or are using the CC1 flag) -- Variable location coverage should go up, as llvm should be able to describe arguments that are never mutated. @djtodoro has also added some additional stats related to call site info in D66525 <https://reviews.llvm.org/D66525>.

Does the variable location coverage statistic use these tags? If so, how? I wouldn't've expected that would be possible - because the variables are in the callee, but the tags are in the caller - so how would the statistic be represented (if 3 out of 5 call sites have the attributes, say - or if the call site is in one object file but the callee is in another object file - how much location coverage is provided by the call site attribute?)

>> and partly practically (knowing the value of the parameter in the caller doesn't necessarily mean you know the value of the parameter at various points in the callee - parameters are usually mutable, so the callee might've modified the parameter & the callee's value won't reflect that))
> 
> Yes, good point, parameters are generally mutable but clang doesn't request call site parameter info for mutable arguments right now. Doing so would require some extra debug info support (a bit that says "hey, not sure this value is up-to-date!"), and this just hasn't been implemented yet.

(also tricky if the caller's version of the parameter is mutable, but the callee's is not - eg: you pass a copy of the int "foo" - the local copy in the caller gets the call site parameter, but then during the execution of the callee, something causes the original "foo" to have its value changed (perhaps someone else has a pointer to foo, etc... ))


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67410/new/

https://reviews.llvm.org/D67410





More information about the llvm-commits mailing list