"run", and executable file/symtab association?

Randolph Chung
2006-02-15T01:57:56Z

I've been debugging the new checkpoint feature on hppa-linux, and came
across an unexpected "feature" of gdb.

See the transcript below - when the program being debugged dies, I
expect to be able to restart it with "run", but gdb reports an error.
Interestingly, I can still set breakpoints so gdb has not completely
disassociated the program.

tausq@riot:~/gdb/build/gdb/testsuite$ ../gdb gdb.base/checkpoint
GNU gdb 6.4.50.20060214-cvs
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "hppa-linux"...Using host libthread_db
library "/lib/libthread_db.so.1".

(gdb) b 50
Breakpoint 1 at 0x10810: file
../../../gdb-cvs/gdb/testsuite/gdb.base/checkpoint.c, line 50.
(gdb) run
Starting program: /home/tausq/gdb/build/gdb/testsuite/gdb.base/checkpoint

Breakpoint 1, main ()
at ../../../gdb-cvs/gdb/testsuite/gdb.base/checkpoint.c:50
50 lines++; /* breakpoint 1 */
(gdb) checkpoint
checkpoint: fork returned pid 5094.
(gdb) restart 1

Program received signal SIGTRAP, Trace/breakpoint trap.
0xc05903c0 in ?? ()
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (lseek) will be
abandoned.
(gdb) delete
Delete all breakpoints? (y or n) y
(gdb) b 55

Breakpoint 2 at 0x10854: file
../../../gdb-cvs/gdb/testsuite/gdb.base/checkpoint.c, line 55.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program:
No executable file specified.
Use the "file" or "exec-file" command.
(gdb)

The code that outputs the error is corefile.c:get_exec_file(), where
exec_bfd was previously set to NULL by a call to exec_close

Breakpoint 3, exec_close (quitting=0) at ../../gdb-cvs/gdb/exec.c:103
103 int need_symtab_cleanup = 0;
(top-gdb) bt
#0 exec_close (quitting=0) at ../../gdb-cvs/gdb/exec.c:103
#1 0x0016c888 in target_close (targ=0x3a251c, quitting=0)
at ../../gdb-cvs/gdb/target.c:1881
#2 0x00169a9c in pop_target () at ../../gdb-cvs/gdb/target.c:745
#3 0x00073cb0 in kill_inferior () at ../../gdb-cvs/gdb/linux-nat.c:619
#4 0x0012957c in kill_if_already_running (from_tty=1)
at ../../gdb-cvs/gdb/infcmd.c:449
#5 0x001295d0 in run_command_1 (args=0x0, from_tty=1, tbreak_at_main=0)
at ../../gdb-cvs/gdb/infcmd.c:468
#6 0x001298f0 in run_command (args=0x0, from_tty=1)
at ../../gdb-cvs/gdb/infcmd.c:559

I haven't debugged this more yet - is this considered "works as
designed"? or is it a bug?

randolph