gdb displaying incorrect signal names with remote target ?

gdb displaying incorrect signal names with remote target ?

[Julian Smith]

Hello

I'm using a remote target (undodb running on the same machine) with
current gdb (checked out of cvs today), and i'm seeing gdb print the
wrong signal name when the inferior is stopped by a signal.

The inferior is receiving SIGUSR1 (signal number 10 on my i386 Linux
system), thus the remote target sends a packet `S0a' to gdb.

However, gdb is displaying this as:

    Program received signal SIGBUS, Bus error.

- whereas i would expect to see:

    Program received signal SIGUSR1, User defined signal 1.

Does anyone know why this is happening? E.g. does the remote target
need to send any information about the signal number => text mapping
that gdb should be doing ?

I've looked in the gdb source code, and it looks like there are three
different mappings from signal number to text:

$ find ~/gdb_cvs_dir/src/ -name "*.c*"|xargs grep -nw "Bus error"
/home/jules/gdb_cvs_dir/src/gdb/common/signals.c:69:  {"SIGBUS", "Bus error"},
/home/jules/gdb_cvs_dir/src/gdb/proc-events.c:1473:  { SIGBUS, "SIGBUS", "Bus error" },
/home/jules/gdb_cvs_dir/src/libiberty/strsignal.c:113:  ENTRY(SIGBUS, "SIGBUS", "Bus error"),
$

The first of these creates a static array of text strings, and appears
to index into this list using the signal number. The resulting mapping
matches what i'm seeing, where signal 10 is displayed as SIGBUS:

/* This table must match in order and size the signals in enum target_signal
   in src/include/gdb/signals.h.  */
/* *INDENT-OFF* */
static const struct {
     const char *name;
     const char *string;
}   signals [] =
{
  {"0", "Signal 0"},
  {"SIGHUP", "Hangup"},
  {"SIGINT", "Interrupt"},
  {"SIGQUIT", "Quit"},
  {"SIGILL", "Illegal instruction"},
  {"SIGTRAP", "Trace/breakpoint trap"},
  {"SIGABRT", "Aborted"},
  {"SIGEMT", "Emulation trap"},
  {"SIGFPE", "Arithmetic exception"},
  {"SIGKILL", "Killed"},
  {"SIGBUS", "Bus error"},
  {"SIGSEGV", "Segmentation fault"},
  {"SIGSYS", "Bad system call"},
  {"SIGPIPE", "Broken pipe"},
  {"SIGALRM", "Alarm clock"},
  {"SIGTERM", "Terminated"},
  {"SIGURG", "Urgent I/O condition"},
  {"SIGSTOP", "Stopped (signal)"},
  {"SIGTSTP", "Stopped (user)"},
  ...
}

In case it makes any difference, i'm building gdb with a simple `cd src;
./configure && make'. Then running the resulting executable directly in
place. The verion info is:

    GNU gdb (GDB) 7.0.0.20091014-cvs


Thanks for any help.

- Julian

-- 
http://undo-software.com/

Re: gdb displaying incorrect signal names with remote target ?

[Daniel Jacobowitz]

On Wed, Oct 14, 2009 at 09:48:27PM +0100, Julian Smith wrote:
> The inferior is receiving SIGUSR1 (signal number 10 on my i386 Linux
> system), thus the remote target sends a packet `S0a' to gdb.

That's your mistake right there :-)

From the manual:

The `C', `c', `S', `s', `vCont', `vAttach', `vRun', `vStopped', and `?'
packets can receive any of the below as a reply.  Except for `?' and
`vStopped', that reply is only returned when the target halts.  In the
below the exact meaning of "signal number" is defined by the header
`include/gdb/signals.h' in the GDB source code.

-- 
Daniel Jacobowitz
CodeSourcery

Re: gdb displaying incorrect signal names with remote target ?

[Pedro Alves]

On Wednesday 14 October 2009 21:48:27, Julian Smith wrote:
> The inferior is receiving SIGUSR1 (signal number 10 on my i386 Linux
> system), thus the remote target sends a packet `S0a' to gdb.

There's the problem.  The remote target needs to send the
remote protocol code for SIGUSR1 , not the targets'.  That would
be... TARGET_SIGNAL_USR1 = 30.  The manual describes this:

"In the below the exact meaning of @dfn{signal
number} is defined by the header @file{include/gdb/signals.h} in the
@value{GDBN} source code."

... and include/gdb/signals.h says:

/* The numbering of these signals is chosen to match traditional unix
   signals (insofar as various unices use the same numbers, anyway).
   It is also the numbering of the GDB remote protocol.  Other remote
   protocols, if they use a different numbering, should make sure to
   translate appropriately.

-- 
Pedro Alves

Re: gdb displaying incorrect signal names with remote target ?

[Pedro Alves]

On Wednesday 14 October 2009 21:48:27, Julian Smith wrote:
> The inferior is receiving SIGUSR1 (signal number 10 on my i386 Linux
> system), thus the remote target sends a packet `S0a' to gdb.

There's the problem.  The remote target needs to send the
remote protocol code for SIGUSR1 , not the targets'.  That would
be... TARGET_SIGNAL_USR1 = 30.  The manual describes this:

"In the below the exact meaning of @dfn{signal
number} is defined by the header @file{include/gdb/signals.h} in the
@value{GDBN} source code."

... and include/gdb/signals.h says:

/* The numbering of these signals is chosen to match traditional unix
   signals (insofar as various unices use the same numbers, anyway).
   It is also the numbering of the GDB remote protocol.  Other remote
   protocols, if they use a different numbering, should make sure to
   translate appropriately.

-- 
Pedro Alves

Re: gdb displaying incorrect signal names with remote target ?

[Julian Smith]

On Wed, 14 Oct 2009 22:04:57 +0100
Pedro Alves <pedro@codesourcery.com> wrote:

> On Wednesday 14 October 2009 21:48:27, Julian Smith wrote:
> > The inferior is receiving SIGUSR1 (signal number 10 on my i386 Linux
> > system), thus the remote target sends a packet `S0a' to gdb.
> 
> There's the problem.  The remote target needs to send the
> remote protocol code for SIGUSR1 , not the targets'.  That would
> be... TARGET_SIGNAL_USR1 = 30.  The manual describes this:

Ah, i completely missed that.

Apolgies for the noise.

Thanks (and to Daniel J also)

- Julian


> 
> "In the below the exact meaning of @dfn{signal
> number} is defined by the header @file{include/gdb/signals.h} in the
> @value{GDBN} source code."
> 
> ... and include/gdb/signals.h says:
> 
> /* The numbering of these signals is chosen to match traditional unix
>    signals (insofar as various unices use the same numbers, anyway).
>    It is also the numbering of the GDB remote protocol.  Other remote
>    protocols, if they use a different numbering, should make sure to
>    translate appropriately.
> 
> -- 
> Pedro Alves
> 


-- 
http://undo-software.com/