This commit fixes these regressions:
FAIL: gdb.base/maint.exp: mt set per on for expand-symtabs
FAIL: gdb.base/maint.exp: maint set per-command on
caused by commit
1e3b796d58ac ("Change command stats reporting to use
class").
gdb.log shows that the command stats are now printing garbage:
(gdb) mt set per on
Command execution time: -6.-419590 (cpu),
1467139648.-
7706296840 (wall)
Space used:
9809920 (-
33276528 for this command)
(gdb) FAIL: gdb.base/maint.exp: mt set per on for expand-symtabs
while there should have been no output at all.
The stats printing is done from within the scoped_command_stats's
destructor, depending on whether some flags in the object are set.
The problem is simply that scoped_command_stats's ctor misses clearing
those flags on some paths.
Since scoped_command_stats objects are allocated on the stack, whether
you'll see the regression simply depends on whatever happens to
already be on the stack space the object occupies.
gdb/ChangeLog:
2016-10-28 Pedro Alves <palves@redhat.com>
* maint.c (scoped_command_stats::scoped_command_stats): Clear
m_space_enabled, m_time_enabled and m_symtab_enabled.
+2016-10-28 Pedro Alves <palves@redhat.com>
+
+ * maint.c (scoped_command_stats::scoped_command_stats): Clear
+ m_space_enabled, m_time_enabled and m_symtab_enabled.
+
2016-10-28 Markus Metzger <markus.t.metzger@intel.com>
* btrace.c (bfun_s): New typedef.
m_space_enabled = 1;
#endif
}
+ else
+ m_space_enabled = 0;
if (msg_type == 0 || per_command_time)
{
gettimeofday (&m_start_wall_time, NULL);
m_time_enabled = 1;
}
+ else
+ m_time_enabled = 0;
if (msg_type == 0 || per_command_symtab)
{
m_start_nr_blocks = nr_blocks;
m_symtab_enabled = 1;
}
+ else
+ m_symtab_enabled = 0;
/* Initalize timer to keep track of how long we waited for the user. */
reset_prompt_for_continue_wait_time ();