* -g and -fvar-tracking @ 2018-04-24 7:06 Sandra Loosemore 2018-04-24 7:18 ` Jakub Jelinek 0 siblings, 1 reply; 3+ messages in thread From: Sandra Loosemore @ 2018-04-24 7:06 UTC (permalink / raw) To: gcc; +Cc: Don Breazeal 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: -g and -fvar-tracking 2018-04-24 7:06 -g and -fvar-tracking Sandra Loosemore @ 2018-04-24 7:18 ` Jakub Jelinek 2018-04-25 3:17 ` Sandra Loosemore 0 siblings, 1 reply; 3+ messages in thread From: Jakub Jelinek @ 2018-04-24 7:18 UTC (permalink / raw) To: Sandra Loosemore; +Cc: gcc, Don Breazeal 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: -g and -fvar-tracking 2018-04-24 7:18 ` Jakub Jelinek @ 2018-04-25 3:17 ` Sandra Loosemore 0 siblings, 0 replies; 3+ messages in thread From: Sandra Loosemore @ 2018-04-25 3:17 UTC (permalink / raw) To: Jakub Jelinek; +Cc: gcc, Don Breazeal 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-04-24 16:49 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-04-24 7:06 -g and -fvar-tracking Sandra Loosemore 2018-04-24 7:18 ` Jakub Jelinek 2018-04-25 3:17 ` Sandra Loosemore
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).