-g and -fvar-tracking

-g and -fvar-tracking

[Sandra Loosemore]

Can somebody remind me why using -g doesn't also enable -fvar-tracking 
by default?  At least for -g2, which is supposed to emit debug 
information about local variables?  It seems kind of counterintuitive to 
me that specifying a -O option enables a pass to collect better debug 
information but specifying -g to request debuggable code doesn't.  :-S

-Sandra

Re: -g and -fvar-tracking

[Jakub Jelinek]

On Mon, Apr 23, 2018 at 10:15:57PM -0600, Sandra Loosemore wrote:
> Can somebody remind me why using -g doesn't also enable -fvar-tracking by
> default?  At least for -g2, which is supposed to emit debug information
> about local variables?  It seems kind of counterintuitive to me that
> specifying a -O option enables a pass to collect better debug information
> but specifying -g to request debuggable code doesn't.  :-S

Because var-tracking is compile time expensive and for -O0 not needed in
most cases (variable live in memory).  It would be nice to have only partial
fast var-tracking for -O0, that would track only variables that don't live
in memory or say parameters before they are assigned to their slots or
similarly VLAs before they make it into their slots.  That said, for -O0 it
would need to be really fast.

We also have -Og which is supposed to provide good debugging experience
while optimizing a little, the worst problem with that is that in -Og we
don't artificially extend lifetime of variables till end of their scope, so
if some value is not needed after some point in the middle of the scope,
then if there is no way to compute that value anymore we can't provide the
value.

	Jakub

Re: -g and -fvar-tracking

[Sandra Loosemore]

On 04/24/2018 01:05 AM, Jakub Jelinek wrote:
> On Mon, Apr 23, 2018 at 10:15:57PM -0600, Sandra Loosemore wrote:
>> Can somebody remind me why using -g doesn't also enable -fvar-tracking by
>> default?  At least for -g2, which is supposed to emit debug information
>> about local variables?  It seems kind of counterintuitive to me that
>> specifying a -O option enables a pass to collect better debug information
>> but specifying -g to request debuggable code doesn't.  :-S
> 
> Because var-tracking is compile time expensive and for -O0 not needed in
> most cases (variable live in memory).  It would be nice to have only partial
> fast var-tracking for -O0, that would track only variables that don't live
> in memory or say parameters before they are assigned to their slots or
> similarly VLAs before they make it into their slots.  That said, for -O0 it
> would need to be really fast.

Hmmm.  There is a GDB test case (gdb.base/store.c) that is doing:

charest
wack_charest (register charest u, register charest v)
{
   register charest l = u, r = v;
   l = add_charest (l, r);
   return l + r;
}

and expecting l and r to have meaningful debug information.  If GCC 
can't produce it with just -g and that is intentional behavior, then it 
sounds like the GDB test case needs to be either fixed or XFAILed.  The 
specific failure we're seeing is that r's debug information is pointing 
only at its initial location in a call-clobbered register, even though 
it's moved to a different place before the call.  With -fvar-tracking it 
produces better debug information, and with any kind of optimization 
enabled it produces better code.  :-P

> We also have -Og which is supposed to provide good debugging experience
> while optimizing a little, the worst problem with that is that in -Og we
> don't artificially extend lifetime of variables till end of their scope, so
> if some value is not needed after some point in the middle of the scope,
> then if there is no way to compute that value anymore we can't provide the
> value.

TBH I'm personally more inclined to use just -O rather than -Og for 
building code for hand debugging.  But it looks like the GDB testsuite 
builds its test programs with -g only by default.

-Sandra