infrun debug output: print enum gdb_signal symbol names instead of POSIX signal names.

The other day while debugging something related to random signals, I
got confused with "set debug infrun 1" output, for it said:

 infrun: TARGET_WAITKIND_STOPPED
 infrun: stop_pc = 0x323d4e8b94
 infrun: random signal 20

On GNU/Linux, 20 is SIGTSTP.  For some reason, it took me a few
minutes to realize that 20 is actually a GDB signal number, not a
target signal number (duh!).  In any case, I propose making GDB's
output clearer here:

One way would be to use gdb_signal_to_name, like already used
elsewhere:

 infrun: TARGET_WAITKIND_STOPPED
 infrun: stop_pc = 0x323d4e8b94
 infrun: random signal SIGCHLD (20)

but I think that might confuse someone too ("20? Why does GDB believe
SIGCHLD is 20?").  So I thought of printing the enum string instead:

 infrun: TARGET_WAITKIND_STOPPED
 infrun: stop_pc = 0x323d4e8b94
 infrun: random signal GDB_SIGNAL_CHLD (20)

Looking at a more complete infrun debug log, we had actually printed
the (POSIX) signal name name a bit before:

 infrun: target_wait (-1, status) =
 infrun:   9300 [Thread 0x7ffff7fcb740 (LWP 9300)],
 infrun:   status->kind = stopped, signal = SIGCHLD
 ...
 infrun: TARGET_WAITKIND_STOPPED
 infrun: stop_pc = 0x323d4e8b94
 infrun: random signal 20

So I'm now thinking that it'd be even better to make infrun output
consistently use the enum symbol string, like so:

 infrun: clear_proceed_status_thread (Thread 0x7ffff7fca700 (LWP 25663))
 infrun: clear_proceed_status_thread (Thread 0x7ffff7fcb740 (LWP 25659))
- infrun: proceed (addr=0xffffffffffffffff, signal=144, step=1)
+ infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT, step=1)
- infrun: resume (step=1, signal=0), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 25659)] at 0x400700
+ infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 25659)] at 0x400700
 infrun: wait_for_inferior ()
 infrun: target_wait (-1, status) =
 infrun:   25659 [Thread 0x7ffff7fcb740 (LWP 25659)],
- infrun:   status->kind = stopped, signal = SIGCHLD
+ infrun:   status->kind = stopped, signal = GDB_SIGNAL_CHLD
 infrun: infwait_normal_state
 infrun: TARGET_WAITKIND_STOPPED
 infrun: stop_pc = 0x400700
- infrun: random signal 20
+ infrun: random signal (GDB_SIGNAL_CHLD)
 infrun: random signal, keep going
- infrun: resume (step=1, signal=20), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 25659)] at 0x400700
+ infrun: resume (step=1, signal=GDB_SIGNAL_CHLD), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 25659)] at 0x400700
 infrun: prepare_to_wait
 infrun: target_wait (-1, status) =
 infrun:   25659 [Thread 0x7ffff7fcb740 (LWP 25659)],
- infrun:   status->kind = stopped, signal = SIGTRAP
+ infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
 infrun: infwait_normal_state
 infrun: TARGET_WAITKIND_STOPPED
 infrun: stop_pc = 0x400704
 infrun: stepi/nexti
 infrun: stop_stepping

GDB's signal numbers are public and hardcoded (see
include/gdb/signals.h), so there's really no need to clutter the
output with numeric values in some places while others not.  Replacing
the magic "144" with GDB_SIGNAL_DEFAULT in "proceed"'s debug output
(see above) I think is quite nice.

I posit that all this makes it clearer to newcomers that GDB has its
own signal numbering (and that there must be some mapping going on).

Tested on x86_64 Fedora 17.

gdb/
2013-10-23  Pedro Alves  <palves@redhat.com>

	* common/gdb_signals.h (gdb_signal_to_symbol_string): Declare.
	* common/signals.c: Include "gdb_assert.h".
	(signals): New field 'symbol'.
	(SET): Use the 'symbol' parameter.
	(gdb_signal_to_symbol_string): New function.
	* infrun.c (handle_inferior_event) <random signal>: In debug
	output, print the random signal enum as string in addition to its
	number.
	* target/waitstatus.c (target_waitstatus_to_string): Print the
	signal's enum value as string instead of the (POSIX) signal name.

0 files changed, 0 insertions, 0 deletions