<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 26, 2021 at 12:10 PM <<a href="mailto:stephen.tozer@sony.com">stephen.tozer@sony.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">




<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
> when you say "more variables being emitted to DWARF with 0% coverage" - what do you mean by that? Are we counting a variable with no location attribute as being 100% covered, because it isn't partially covered? Could we instead count such variables as 0%
 covered?</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Not exactly, it's that we aren't considering them at all. If we have 2 variables <code>
a</code> and <code>b</code> with 100% and 50% coverage respectively, we'd have 75% total coverage (assuming they both occupy identically sized scopes). If a new optimization causes us to drop
<code>b</code>'s coverage to 0%, then we would expect the overall coverage to drop to 50%. However, we may end up dropping
<code>b</code> entirely from the DWARF,</div></div></blockquote><div><br></div><div>When does this ^ happen? In optimized builds we include all local variables in a "variables" attachment to the DISubprogram, so we shouldn't be losing variables entirely. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> in which case the <code>dwarfdump</code> statistics see that we only have 1 variable and it has 100% coverage, giving us 100% overall coverage. While it would be accurate to count these missing variables as 0% covered,
 if there's no mention of them in the DWARF then there is no way for <code>dwarfdump</code> to know they exist.<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
I'm not actually sure what causes variables to be dropped from the DWARF entirely, as opposed to them existing but having an unknown location for their entire scope; however, outside of our desire to use
<code>dwarfdump</code> to analyze our debug info it's simply more efficient to omit variables with no location, since they inflate the debug info size and I don't believe there's any practical value in having them.</div></div></blockquote><div><br>I think it's pretty important that we keep them. It helps a user understand that they've not mistyped the name of a variable, etc - that it's there, but has no location is distinct from it not being there at all. A marginal motivation is that this can also produce even more surprising behavior in the case of shadowing - if a shadowing variable is omitted entirely, when the user tries to print it they might get the shadowed variable and mistake it for the shadowing one. Admittedly DWARF doesn't make much of an effort to be reproduce shadowing perfectly - functions and other entities that are never referenced are generally omitted and can produce this kind of shadowing/incorrect lookup behavior - so it's a marginal motivation.<br><br>- Dave<br> </div></div></div>