gdb and binutils branch master updated. d993ade58be7c10e1da7ab2bedff7a0b97dceec0

[palves at sourceware dot org]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  d993ade58be7c10e1da7ab2bedff7a0b97dceec0 (commit)
      from  0a75c11540af8e7675a98694ede350f03abc2576 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d993ade58be7c10e1da7ab2bedff7a0b97dceec0

commit d993ade58be7c10e1da7ab2bedff7a0b97dceec0
Author: Pedro Alves <palves@redhat.com>
Date:   Wed Oct 23 16:14:53 2013 +0100

    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.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog            |   13 +++++++++++++
 gdb/common/gdb_signals.h |    4 ++++
 gdb/common/signals.c     |   11 ++++++++++-
 gdb/infrun.c             |   15 +++++++++------
 gdb/target/waitstatus.c  |    6 ++++--
 5 files changed, 40 insertions(+), 9 deletions(-)


hooks/post-receive
-- 
gdb and binutils