SIGTRAP or SIG32 when remote debugging threads

SIGTRAP or SIG32 when remote debugging threads

[Lukas Heiniger]

I'm trying to do thread debugging on an arm7 target with a gdb 6.0 snapshot 
and gdbserver. I've been searching this list for two days now but haven't 
found an answer to my problem.

I get a SIG32 when a new thread is created with pthread_create(...). If I use

handle SIG32 nostop
handle SIG32 noprint

thread creation seems to work. However, I still see only one (main) thread 
with 'info thread'
and receive a SIGTRAP when setting a breakpoint inside a thread.

I have libthread_db-1.0.so
       libthread_db.so -> libthread_db.so.1
       libthread_db.so.1 -> libthread_db-1.0.so

installed in usr/lib on the target and gdbserver seems to load it (there's no 
message, but gdbserver complains
if I remove those libraries).

the application and libpthread-0.8.so in /lib are unstripped.


Here is a session log in case it might help:

	This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux"...
	(gdb) set debug remote 1
	(gdb) handle SIG32 nostop noprint
	Signal        Stop      Print   Pass to program Description
	SIG32         No        No      Yes             Real-time event 32
	(gdb) target remote /dev/ttyS0
	Remote debugging using /dev/ttyS0
	Sending packet: $Hc-1#09...Ack
	Packet received: OK
	Sending packet: $qC#b4...Ack
	Packet received:
	Sending packet: $qOffsets#4b...Ack
	Packet received:
	Sending packet: $?#3f...Ack
	Packet received: T050b:00000000;0d:40feffbf;0f:70250040;
	Sending packet: $m40002570,4#5f...Ack
	Packet received: 0d00a0e1
	0x40002570 in ?? ()
	Sending packet: $m202ad84,b0#f0...Ack
	Packet received: 
0100000001000000010000005700000001000000190100000c000000301200020d00000054d10102040000003001000205000000780a000206000000480400020a0000006e0300000b0000001000000015000000000000000300000000ac020202000000e8020000140000001100000017000000480f000211000000400f000212000000080000001300000008000000feffff6fc00e0002ffffff6f03000000f0ffff6ffa0d00020000000000000000
	Sending packet: $qSymbol::#5b...Ack
	Packet received: qSymbol:5f5f707468726561645f746872656164735f6576656e7473
	Packet qSymbol (symbol-lookup) is supported
	Sending packet: 
$qSymbol::5f5f707468726561645f746872656164735f6576656e7473#47...Ack
	Packet received: OK
	(gdb) c

	...

	Program received signal SIGTRAP, Trace/breakpoint trap.
	Sending packet: $M4000f6c0,4:000050e3#97...Ack
	Packet received: OK
	Sending packet: $M20018ec,4:0670a0e1#9e...Ack
	Packet received: OK
	Sending packet: $M201b9a8,4:0510a0e1#9b...Ack
	Packet received: OK
	Sending packet: $m2001930,4#2c...Ack
	Packet received: 000053e3
	0x02001930 in main () at main/main.c:174
	174             while( bPowerDownFlag == false );

--
Any help would be much appreciated

Lukas Heinier

Re: SIGTRAP or SIG32 when remote debugging threads

[Daniel Jacobowitz]

On Fri, Mar 19, 2004 at 11:07:34AM +0100, Lukas Heiniger wrote:
> I'm trying to do thread debugging on an arm7 target with a gdb 6.0 snapshot 
> and gdbserver. I've been searching this list for two days now but haven't 
> found an answer to my problem.

Have you set solib-absolute-prefix?  It doesn't look like it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: SIGTRAP or SIG32 when remote debugging threads

[Lukas Heiniger]

On Friday 19 March 2004 18:28, Daniel Jacobowitz wrote:
> On Fri, Mar 19, 2004 at 11:07:34AM +0100, Lukas Heiniger wrote:
> > I'm trying to do thread debugging on an arm7 target with a gdb 6.0
> > snapshot and gdbserver. I've been searching this list for two days now
> > but haven't found an answer to my problem.
>
> Have you set solib-absolute-prefix?  It doesn't look like it.

Thanks

I do have set solib-absolute-prefix to .../target_fs

where target_fs contains a copy of the target file system (including /lib 
and /usr/lib ...)

solib-search-path is not set, however. I tried various combinations with
solib-search-path and solib-absolute-prefix but still I always get

Program received signal SIG32, Real-time event 32.
0x40088534 in ?? ()

Lukas Heiniger

Re: SIGTRAP or SIG32 when remote debugging threads

[Daniel Jacobowitz]

On Mon, Mar 22, 2004 at 09:47:46AM +0100, Lukas Heiniger wrote:
> On Friday 19 March 2004 18:28, Daniel Jacobowitz wrote:
> > On Fri, Mar 19, 2004 at 11:07:34AM +0100, Lukas Heiniger wrote:
> > > I'm trying to do thread debugging on an arm7 target with a gdb 6.0
> > > snapshot and gdbserver. I've been searching this list for two days now
> > > but haven't found an answer to my problem.
> >
> > Have you set solib-absolute-prefix?  It doesn't look like it.
> 
> Thanks
> 
> I do have set solib-absolute-prefix to .../target_fs
> 
> where target_fs contains a copy of the target file system (including /lib 
> and /usr/lib ...)
> 
> solib-search-path is not set, however. I tried various combinations with
> solib-search-path and solib-absolute-prefix but still I always get
> 
> Program received signal SIG32, Real-time event 32.
> 0x40088534 in ?? ()

You may have to debug GDB to find out why it is not loading shared
libraries then.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: SIGTRAP or SIG32 when remote debugging threads

[Lukas Heiniger]

On Monday 22 March 2004 15:22, Daniel Jacobowitz wrote:
> On Mon, Mar 22, 2004 at 09:47:46AM +0100, Lukas Heiniger wrote:
> > On Friday 19 March 2004 18:28, Daniel Jacobowitz wrote:
> > > On Fri, Mar 19, 2004 at 11:07:34AM +0100, Lukas Heiniger wrote:
> > > > I'm trying to do thread debugging on an arm7 target with a gdb 6.0
> > > > snapshot and gdbserver. I've been searching this list for two days
> > > > now but haven't found an answer to my problem.
> > >
> > > Have you set solib-absolute-prefix?  It doesn't look like it.
> >
> > Thanks
> >
> > I do have set solib-absolute-prefix to .../target_fs
> >
> > where target_fs contains a copy of the target file system (including /lib
> > and /usr/lib ...)
> >
> > solib-search-path is not set, however. I tried various combinations with
> > solib-search-path and solib-absolute-prefix but still I always get
> >
> > Program received signal SIG32, Real-time event 32.
> > 0x40088534 in ?? ()
>
> You may have to debug GDB to find out why it is not loading shared
> libraries then.

Did that and it helped. 
It seems that the problem was that I specified the inferior with 'symbol-file' 
only. exec_bfd wasn't set then, and no libraries were loaded. Now I specify 
the file with 'exec-file' or when starting gdb.
Besides that, some of the libraries in <solib-absolute-prefix>/lib were 
stripped.

However some things are still suspicious if you look at my last session:





--
lheiniger@linux:/home/hynix/arm/bin> arm-linux-gdb /home/hynix/app
GNU gdb 20040318
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 "--host=i686-pc-linux-gnu --target=arm-linux"...
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
0x40002570 in ?? ()
(gdb) set solib-absolute-prefix /home/hynix/arm/arm-linux
(gdb) set solib-absolute-prefix /home/hynix/arm/arm-linux
(gdb) c
Continuing.

Program received signal SIG32, Real-time event 32.
0x40088534 in ?? ()

(gdb) set solib-absolute-prefix /home/hynix/arm/arm-linux
Reading symbols from /home/hynix/arm/arm-linux/lib/libm.so.6...done.
Loaded symbols for /home/hynix/arm/arm-linux/lib/libm.so.6
Reading symbols from /home/hynix/arm/arm-linux/lib/libpthread.so.0...done.
Loaded symbols for /home/hynix/arm/arm-linux/lib/libpthread.so.0
Reading symbols from /home/hynix/arm/arm-linux/lib/libc.so.6...done.
Loaded symbols for /home/hynix/arm/arm-linux/lib/libc.so.6
Reading symbols from /home/hynix/arm/arm-linux/lib/ld-linux.so.2...done.
Loaded symbols for /home/hynix/arm/arm-linux/lib/ld-linux.so.2
(gdb) i threads
  3 Thread 1026  0x400e1ee4 in getegid () from /home/hynix/arm/arm-linux/lib/
libc.so.6
  2 Thread 2049  0x400fa7b8 in tcsetattr (fd=1, optional_actions=1, 
termios_p=0x0) at ../sysdeps/unix/sysv/linux/tcsetattr.c:92
  1 Thread 1024  0x40088534 in __sigsuspend (set=0xbffffc6c) at ../sysdeps/
unix/sysv/linux/sigsuspend.c:54

(gdb) l vcif_RxThread
...
(gdb) b 712
Breakpoint 1 at 0x201fc30: file ASFINAG/vcif/src/vcif.c, line 712.
(gdb) c
Continuing.
[New Thread 8201]
[Switching to Thread 8201]

Breakpoint 1, vcif_RxThread (Dummy=0x0) at vcif.c:712
712                     BytesRead = read(s_UartDevice, Buf, READ_SIZE);
(gdb)

--


1. Why does gdb wait with loading the libraries until I 'set 
solib-absolute-prefix...' after the first SIG32 instead of loading them in 
the first place?

2. The files referenced in threads 2 and 1 seem to be host files. They are not 
part of the target filesys.
I had a breakpoint in solib_open and every library that was loaded seemed to 
be available in the path set with 'solib-absolute-prefix'. Why does it still 
refer to host files? 

Any Ideas? 

Thanks
Lukas Heiniger

Re: SIGTRAP or SIG32 when remote debugging threads

[Daniel Jacobowitz]

On Tue, Mar 23, 2004 at 05:55:45PM +0100, Lukas Heiniger wrote:
> (gdb) set solib-absolute-prefix /home/hynix/arm/arm-linux
> (gdb) set solib-absolute-prefix /home/hynix/arm/arm-linux
> (gdb) c
> Continuing.
> 
> Program received signal SIG32, Real-time event 32.
> 0x40088534 in ?? ()
> 
> (gdb) set solib-absolute-prefix /home/hynix/arm/arm-linux
> Reading symbols from /home/hynix/arm/arm-linux/lib/libm.so.6...done.
> Loaded symbols for /home/hynix/arm/arm-linux/lib/libm.so.6

This suggests that the dynamic linker breakpoint wasn't hit.  You may
want to use 'set debug remote 1' and 'set debug target 1' to try to
figure out where the breakpoint was set, and why it wasn't hit.

>   2 Thread 2049  0x400fa7b8 in tcsetattr (fd=1, optional_actions=1, 
> termios_p=0x0) at ../sysdeps/unix/sysv/linux/tcsetattr.c:92
>   1 Thread 1024  0x40088534 in __sigsuspend (set=0xbffffc6c) at ../sysdeps/
> unix/sysv/linux/sigsuspend.c:54

These are taken from the debug information; they're relative to the
objdir when your target glibc was built.  They don't necessarily refer
to on-disk files.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: SIGTRAP or SIG32 when remote debugging threads

[Lukas Heiniger]

On Tuesday 23 March 2004 20:13, Daniel Jacobowitz wrote:
> On Tue, Mar 23, 2004 at 05:55:45PM +0100, Lukas Heiniger wrote:
> > (gdb) set solib-absolute-prefix /home/hynix/arm/arm-linux
> > (gdb) set solib-absolute-prefix /home/hynix/arm/arm-linux
> > (gdb) c
> > Continuing.
> >
> > Program received signal SIG32, Real-time event 32.
> > 0x40088534 in ?? ()
> >
> > (gdb) set solib-absolute-prefix /home/hynix/arm/arm-linux
> > Reading symbols from /home/hynix/arm/arm-linux/lib/libm.so.6...done.
> > Loaded symbols for /home/hynix/arm/arm-linux/lib/libm.so.6
>
> This suggests that the dynamic linker breakpoint wasn't hit.  You may
> want to use 'set debug remote 1' and 'set debug target 1' to try to
> figure out where the breakpoint was set, and why it wasn't hit.
>
> >   2 Thread 2049  0x400fa7b8 in tcsetattr (fd=1, optional_actions=1,
> > termios_p=0x0) at ../sysdeps/unix/sysv/linux/tcsetattr.c:92
> >   1 Thread 1024  0x40088534 in __sigsuspend (set=0xbffffc6c) at
> > ../sysdeps/ unix/sysv/linux/sigsuspend.c:54
>
> These are taken from the debug information; they're relative to the
> objdir when your target glibc was built.  They don't necessarily refer
> to on-disk files.

Thanks again for your quick answer.

It looks like setting and hitting the shlib event breakpoint works.

As much as I understand, the problem is that in the first target_xfer_memory
(see below) the pointer to the dynamic section is 0 (in the line that begins
with 15 00 ...). elf_locate_base therefore returns 0 for the debug_base and
the list of currently loaded shared objects is not built.
After the program has been continued, the second target_xfer_memory (invoked
upon specifiying solib-absoulute-prefix again) returns a valid pointer
to the dynamic section and the libs are loaded.

Is this normal behaviour or is there anything I can do about it?

Lukas Heiniger

...
(gdb) set solib-absolute-prefix /home/hynix/target_fs
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
Sending packet: $Hc-1#09...Ack
Packet received: OK
Sending packet: $qC#b4...Ack
Packet received:
Sending packet: $qOffsets#4b...Ack
Packet received:
Sending packet: $?#3f...Ack
Packet received: T050b:00000000;0d:50feffbf;0f:70250040;
target_wait (-1, status) = 42000,   status->kind = stopped, signal = SIGTRAP
target_terminal_ours ()
Sending packet: $m40002570,4#5f...Ack
Packet received: 0d00a0e1
target_xfer_memory (0x40002570, xxx, 4, read, xxx) = 4, bytes = 0d 00 a0 e1
0x40002570 in ?? ()
Sending packet: $m20328e4,b0#c3...Ack
Packet received:
...
target_xfer_memory (0x20328e4, xxx, 176, read, xxx) = 176, bytes =
 01 00 00 00 01 00 00 00 01 00 00 00 57 00 00 00
 01 00 00 00 19 01 00 00 0c 00 00 00 84 12 00 02
 0d 00 00 00 74 14 02 02 04 00 00 00 30 01 00 02
 05 00 00 00 a0 0a 00 02 06 00 00 00 50 04 00 02
 0a 00 00 00 83 03 00 00 0b 00 00 00 10 00 00 00
 15 00 00 00 00 00 00 00 03 00 00 00 5c 27 03 02
 02 00 00 00 f0 02 00 00 14 00 00 00 11 00 00 00
 17 00 00 00 94 0f 00 02 11 00 00 00 84 0f 00 02
 12 00 00 00 10 00 00 00 13 00 00 00 08 00 00 00
 fe ff ff 6f 04 0f 00 02 ff ff ff 6f 03 00 00 00
 f0 ff ff 6f 38 0e 00 02 00 00 00 00 00 00 00 00
Sending packet: $qSymbol::#5b...Ack
Packet received: qSymbol:5f5f707468726561645f746872656164735f6576656e7473
Packet qSymbol (symbol-lookup) is supported
Sending packet: 
$qSymbol::5f5f707468726561645f746872656164735f6576656e7473#47...Ack
Packet received: OK
(gdb) maint info breakpoints
Num Type           Disp Enb Address    What
-1  longjmp resume keep n   0x00000000
-2  shlib events   keep y   0x4000c3fc
(gdb) c
Continuing.
Sending packet: $Z0,4000c3fc,4#39...Ack
Packet received:
Packet Z0 (software-breakpoint) is NOT supported
Sending packet: $m4000c3fc,4#f0...Ack
Packet received: 002094e5
target_xfer_memory (0x4000c3fc, xxx, 4, read, xxx) = 4, bytes = 00 20 94 e5
Sending packet: $X4000c3fc,0:#11...Ack
Packet received:
binary downloading NOT suppported by target
Sending packet: $M4000c3fc,4:01009fef#35...Ack
Packet received: OK
target_xfer_memory (0x4000c3fc, xxx, 4, write, xxx) = 4, bytes =
 01 00 9f ef
target_insert_breakpoint (0x4000c3fc, xxx) = 0
target_terminal_inferior ()
Sending packet: $vCont?#49...Ack
Packet received: vCont;c;C;s;S
Packet vCont (verbose-resume) is supported
Sending packet: $vCont;c#a8...Ack
target_resume (-1, continue, 0)
Packet received: T4d0b:68fcffbf;0d:4cfcffbf;0f:34850840;
target_wait (-1, status) = 42000,   status->kind = stopped, signal = SIG32
target_terminal_ours_for_output ()

Program received signal SIG32, Real-time event 32.
Sending packet: $M4000c3fc,4:002094e5#d3...Ack
Packet received: OK
target_xfer_memory (0x4000c3fc, xxx, 4, write, xxx) = 4, bytes = 00 20 94 e5
target_remove_breakpoint (0x4000c3fc, xxx) = 0
target_terminal_ours ()
Sending packet: $m40088534,4#6d...Ack
Packet received: 0040a0e1
target_xfer_memory (0x40088534, xxx, 4, read, xxx) = 4, bytes = 00 40 a0 e1
0x40088534 in ?? ()

(gdb) set solib-absolute-prefix /home/hynix/target_fs
Sending packet: $m20328e4,b0#c3...Ack
Packet received:
...
target_xfer_memory (0x20328e4, xxx, 176, read, xxx) = 176, bytes =
 01 00 00 00 01 00 00 00 01 00 00 00 57 00 00 00
 01 00 00 00 19 01 00 00 0c 00 00 00 84 12 00 02
 0d 00 00 00 74 14 02 02 04 00 00 00 30 01 00 02
 05 00 00 00 a0 0a 00 02 06 00 00 00 50 04 00 02
 0a 00 00 00 83 03 00 00 0b 00 00 00 10 00 00 00
 15 00 00 00 50 d2 01 40 03 00 00 00 5c 27 03 02
 02 00 00 00 f0 02 00 00 14 00 00 00 11 00 00 00
 17 00 00 00 94 0f 00 02 11 00 00 00 84 0f 00 02
 12 00 00 00 10 00 00 00 13 00 00 00 08 00 00 00
 fe ff ff 6f 04 0f 00 02 ff ff ff 6f 03 00 00 00
 f0 ff ff 6f 38 0e 00 02 00 00 00 00 00 00 00 00
Sending packet: $m4001d254,4#91...Ack
Packet received: 70d20140
target_xfer_memory (0x4001d254, xxx, 4, read, xxx) = 4, bytes =
 70 d2 01 40
Sending packet: $m4001d270,14#c0...Ack

... now loading shared libs ...

Re: SIGTRAP or SIG32 when remote debugging threads

[Daniel Jacobowitz]

On Wed, Mar 24, 2004 at 02:11:16PM +0100, Lukas Heiniger wrote:
> It looks like setting and hitting the shlib event breakpoint works.

Not to me.  Is 0x40002570 the shlib event breakpoint, and if so, why
are you stopped there instead of at the first instruction in the
program?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: SIGTRAP or SIG32 when remote debugging threads

[Lukas Heiniger]

On Wednesday 24 March 2004 15:39, Daniel Jacobowitz wrote:
> On Wed, Mar 24, 2004 at 02:11:16PM +0100, Lukas Heiniger wrote:
> > It looks like setting and hitting the shlib event breakpoint works.
>
> Not to me.  Is 0x40002570 the shlib event breakpoint, and if so, why
> are you stopped there instead of at the first instruction in the
> program?

According to 'maint info breakpoints' (you can find it approximately in the 
middle of my last session) the shlib event breakpoint is located at 
0x4000c3fc. After entering 'continue', gdb seems to set a breakpoint there. 
The instruction is restored after SIG32 has been received.

I think that 0x40002570 actually is the first instruction in the program.

Re: SIGTRAP or SIG32 when remote debugging threads

[Daniel Jacobowitz]

On Wed, Mar 24, 2004 at 04:03:13PM +0100, Lukas Heiniger wrote:
> On Wednesday 24 March 2004 15:39, Daniel Jacobowitz wrote:
> > On Wed, Mar 24, 2004 at 02:11:16PM +0100, Lukas Heiniger wrote:
> > > It looks like setting and hitting the shlib event breakpoint works.
> >
> > Not to me.  Is 0x40002570 the shlib event breakpoint, and if so, why
> > are you stopped there instead of at the first instruction in the
> > program?
> 
> According to 'maint info breakpoints' (you can find it approximately in the 
> middle of my last session) the shlib event breakpoint is located at 
> 0x4000c3fc. After entering 'continue', gdb seems to set a breakpoint there. 
> The instruction is restored after SIG32 has been received.
> 
> I think that 0x40002570 actually is the first instruction in the program.

In that case the breakpoint was not hit, just set, according to your
log.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: SIGTRAP or SIG32 when remote debugging threads

[Lukas Heiniger]

On Wednesday 24 March 2004 16:07, Daniel Jacobowitz wrote:
> On Wed, Mar 24, 2004 at 04:03:13PM +0100, Lukas Heiniger wrote:
> > On Wednesday 24 March 2004 15:39, Daniel Jacobowitz wrote:
> > > On Wed, Mar 24, 2004 at 02:11:16PM +0100, Lukas Heiniger wrote:
> > > > It looks like setting and hitting the shlib event breakpoint works.
> > >
> > > Not to me.  Is 0x40002570 the shlib event breakpoint, and if so, why
> > > are you stopped there instead of at the first instruction in the
> > > program?
> >
> > According to 'maint info breakpoints' (you can find it approximately in
> > the middle of my last session) the shlib event breakpoint is located at
> > 0x4000c3fc. After entering 'continue', gdb seems to set a breakpoint
> > there. The instruction is restored after SIG32 has been received.
> >
> > I think that 0x40002570 actually is the first instruction in the program.
>
> In that case the breakpoint was not hit, just set, according to your
> log.


Yeah, you're right (of course). Let me see if I got the mechanisms right (I 
hope I don't go to much into details):

1. When I start the gdb (i.e. when I type 'target remote /dev/ttyS0'), it will 
try to set a break point in the dynamic linker (creating an inferior hook). 
When this special breakpoint was hit, gdb would examine the linker and load 
in any shared libs.

2. Setting the shlib bp is done by enable_break. enable_break first assumes 
that the target is running 

(is this the case in remote debugging ?) 

and tries to get the dynamic linker base from the shared library table. This 
fails because the inferior returns 0 for the debug_base in svr4_current_sos.
So (comment from the code): /* Otherwise we find the dynamic linker's base 
address by examining	 the current pc (which should point at the entry point 
for the dynamic linker) and subtracting the offset of the entry point. */

(Isn't pc pointing at the first instruction of the program?)

so enable_break calculates some value for the breakpoint, which in my case is 
0x4000c3fc. For whatever reason this bp is not hit before the SIG32 appears. 
If this really is the problem, I have no Idea what I could do about it.

3. After the SIG32 has appeared, I set the solib-absolute-prefix again. This 
time the call to svr4_current_sos returns a non-zero value for the debug_base 
and gdb is able to load all the libs.

Lukas Heiniger

Re: SIGTRAP or SIG32 when remote debugging threads

[Daniel Jacobowitz]

On Thu, Mar 25, 2004 at 11:29:32AM +0100, Lukas Heiniger wrote:
> On Wednesday 24 March 2004 16:07, Daniel Jacobowitz wrote:
> > On Wed, Mar 24, 2004 at 04:03:13PM +0100, Lukas Heiniger wrote:
> > > On Wednesday 24 March 2004 15:39, Daniel Jacobowitz wrote:
> > > > On Wed, Mar 24, 2004 at 02:11:16PM +0100, Lukas Heiniger wrote:
> > > > > It looks like setting and hitting the shlib event breakpoint works.
> > > >
> > > > Not to me.  Is 0x40002570 the shlib event breakpoint, and if so, why
> > > > are you stopped there instead of at the first instruction in the
> > > > program?
> > >
> > > According to 'maint info breakpoints' (you can find it approximately in
> > > the middle of my last session) the shlib event breakpoint is located at
> > > 0x4000c3fc. After entering 'continue', gdb seems to set a breakpoint
> > > there. The instruction is restored after SIG32 has been received.
> > >
> > > I think that 0x40002570 actually is the first instruction in the program.
> >
> > In that case the breakpoint was not hit, just set, according to your
> > log.
> 
> 
> Yeah, you're right (of course). Let me see if I got the mechanisms right (I 
> hope I don't go to much into details):
> 
> 1. When I start the gdb (i.e. when I type 'target remote /dev/ttyS0'), it will 
> try to set a break point in the dynamic linker (creating an inferior hook). 
> When this special breakpoint was hit, gdb would examine the linker and load 
> in any shared libs.
> 
> 2. Setting the shlib bp is done by enable_break. enable_break first assumes 
> that the target is running 
> 
> (is this the case in remote debugging ?) 

It should be.

> and tries to get the dynamic linker base from the shared library table. This 
> fails because the inferior returns 0 for the debug_base in svr4_current_sos.
> So (comment from the code): /* Otherwise we find the dynamic linker's base 
> address by examining	 the current pc (which should point at the entry point 
> for the dynamic linker) and subtracting the offset of the entry point. */
> 
> (Isn't pc pointing at the first instruction of the program?)

No, the program is invoked by the dynamic linker.

> so enable_break calculates some value for the breakpoint, which in my case is 
> 0x4000c3fc. For whatever reason this bp is not hit before the SIG32 appears. 
> If this really is the problem, I have no Idea what I could do about it.

You need to figure out if the breakpoint is at the right place or not.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer