Problem with signals using gdb-6.3 on Solaris10

[Steve Williams]

Hi,

I was hoping I could get some help to track down a problem, I need some
pointers of where to start looking in the gdb code.

I am using gdb-6.3 on a sparc-solaris-6.3 SunFireV440. My problems really
started when I installed the October patch cluster for Solaris. It seems all
signal related functionality in gdb broke.

I read the patch cluster release notes and it was stated the release broke
gdb, please use mdb instead. Undetered, I registered a defect in the gdb
defect database (2022) and started to look for a solution.

I first it just seemed to be a problem with quitting gdb (as stated by Sun)
and I devised a patch which fixed the problem and attached it to defect
2022. As I dug deeper into the other problems I found them to be signal
related too. I am sure there is a more deep rooted problem and my patch only
fixes one symptom.

For example, the test testsuite/gdb.base/signals.exp fails on Solaris10 but
not on Solaris9. I have traced through the test using gdb on both versions
of Solaris.

./gdb gdb --nx --command=gdb.cmd testsuite/gdb.base/signals

gdb.cmd
br main
r
set variable count = 0
break handler if 0
set $handler_breakpoint_number = $bpnum
next
next
next
p func1 ()
p count
condition $handler_breakpoint_number
next
next

then I issue:
p func(1)
I get message about interrupted call from gdb

The failure occurs when the backtrace is printed.

On Solaris 9 the session is:
R500.isis.279> ./gdb gdb
GNU gdb 6.3
Copyright 2004 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 "sparc-sun-solaris2.9"...
Setting up the environment for debugging gdb.
Breakpoint 1 at 0x54634: file utils.c, line 849.
Breakpoint 2 at 0xa1ea8: file ./cli/cli-cmds.c, line 193.
 (top-gdb) r --nx --command=~/gdb.cmd testsuite/gdb.base/signals
Starting program:
/export/home/src_dev/R500/vobs/unxloc/sparc64-sun-solaris2.9/gdb-6.3/gdb/gdb
--nx --command=~/gdb.cmd testsuite/gdb.base/signals
GNU gdb 6.3
Copyright 2004 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 "sparc-sun-solaris2.9"...
Breakpoint 1 at 0x1073c: file signals.c, line 46.

Breakpoint 1, main () at signals.c:46
46      signals.c: No such file or directory.
        in signals.c
Breakpoint 2 at 0x106b0: file signals.c, line 22.
49      in signals.c
51      in signals.c
52      in signals.c
$1 = void
$2 = 1
53      in signals.c
54      in signals.c
(gdb) p func1()

Breakpoint 2, handler (sig=14) at signals.c:22
22      in signals.c
The program being debugged stopped while in a function called from GDB.
When the function (func1) is done executing, GDB will silently
stop (instead of continuing to evaluate the expression containing
the function call).
(gdb) bt
#0  handler (sig=14) at signals.c:22
#1  <signal handler called>
#2  func1 () at signals.c:28
#3  <function called from gdb>
#4  main () at signals.c:54
(gdb)

as expected.

On Solaris10:
R500.ramses.285> ./gdb gdb
GNU gdb 6.3
Copyright 2004 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 "sparc-sun-solaris2.10"...
Setting up the environment for debugging gdb.
Breakpoint 1 at 0x55994: file utils.c, line 849.
Breakpoint 2 at 0xa3314: file ./cli/cli-cmds.c, line 193.
(top-gdb) r --nx --command=~/gdb.cmd testsuite/gdb.base/signals
Starting program:
/export/home/src_dev/R500/vobs/unxloc/sparc64-sun-solaris2.10/gdb-6.3/gdb/gd
b --nx --command=~/gdb.cmd testsuite/gdb.base/signals
warning: Lowest section in /lib/libdl.so.1 is .dynamic at 00000094
GNU gdb 6.3
Copyright 2004 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 "sparc-sun-solaris2.10"...
Breakpoint 1 at 0x10724: file signals.c, line 46.

Breakpoint 1, main () at signals.c:46
46      signals.c: No such file or directory.
        in signals.c
Breakpoint 2 at 0x10698: file signals.c, line 22.
49      in signals.c
51      in signals.c
52      in signals.c
$1 = void
$2 = 1
53      in signals.c
54      in signals.c
 (gdb) p func1()

Breakpoint 2, handler (sig=14) at signals.c:22
22      in signals.c
The program being debugged stopped while in a function called from GDB.
When the function (func1) is done executing, GDB will silently
stop (instead of continuing to evaluate the expression containing
the function call).
(gdb) bt
#0  handler (sig=14) at signals.c:22
#1  0xff23fed0 in __sighndlr () from /lib/libc.so.1
#2  0xff234ffc in call_user_handler () from /lib/libc.so.1
#3  0xffbff8ac in ?? ()
#4  0xffbff8ac in ?? ()
Previous frame identical to this frame (corrupt stack?)
(gdb)

Corrupt frame ??

I used the gdb to look at the call setup, it looks the same on both
machines. I also looked at the backtrace command.

On Solaris9 frame 1 has type SIGTRAMP_FRAME, on Solaris 10 frame 1 is a
normal frame.

What I need to know is how to debug the setup of the signal handler frame.
Where is it set up? and how is this code invoked?

Any help would be appreciated

Regards,
Steve Williams