* Gdbserver Threading Issues
@ 2002-12-06 11:20 Paul Mundt
2002-12-06 11:28 ` Daniel Jacobowitz
0 siblings, 1 reply; 12+ messages in thread
From: Paul Mundt @ 2002-12-06 11:20 UTC (permalink / raw)
To: gdb
[-- Attachment #1: Type: text/plain, Size: 575 bytes --]
Hi,
Getting some interesting behavior out of gdbserver now.. (from 5.3
branch). If I run a pthreaded application under it, using Daniel's
patch, I only get a single thread reported, regardless of how many are
created.
However, if I insert a breakpoint into the function each thread is
running, it picks them up fine.. (info threads looks sane then as well).
Also, if the breakpoint is inserted anywhere else (ie, main()), it still
fails to report additional threads.
Suggestions?
Regards,
--
Paul Mundt <paul.mundt@timesys.com>
TimeSys Corporation
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Gdbserver Threading Issues
2002-12-06 11:20 Gdbserver Threading Issues Paul Mundt
@ 2002-12-06 11:28 ` Daniel Jacobowitz
2002-12-06 13:07 ` Paul Mundt
0 siblings, 1 reply; 12+ messages in thread
From: Daniel Jacobowitz @ 2002-12-06 11:28 UTC (permalink / raw)
To: Paul Mundt; +Cc: gdb
On Fri, Dec 06, 2002 at 03:24:34PM -0500, Paul Mundt wrote:
> Hi,
>
> Getting some interesting behavior out of gdbserver now.. (from 5.3
> branch). If I run a pthreaded application under it, using Daniel's
> patch, I only get a single thread reported, regardless of how many are
> created.
>
> However, if I insert a breakpoint into the function each thread is
> running, it picks them up fine.. (info threads looks sane then as well).
>
> Also, if the breakpoint is inserted anywhere else (ie, main()), it still
> fails to report additional threads.
>
> Suggestions?
Not without more information. Look at the remote session transcript,
see what is going on.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Gdbserver Threading Issues
2002-12-06 11:28 ` Daniel Jacobowitz
@ 2002-12-06 13:07 ` Paul Mundt
2002-12-06 13:16 ` Daniel Jacobowitz
0 siblings, 1 reply; 12+ messages in thread
From: Paul Mundt @ 2002-12-06 13:07 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]
On Fri, 2002-12-06 at 14:28, Daniel Jacobowitz wrote:
> Not without more information. Look at the remote session transcript,
> see what is going on.
Hum, still debugging this .. I'm still at a loss as to why breakpoints
would be having any effect on anything, though from the looks of it the
newly created threads are tracked just fine by
thread_db_find_new_threads() in gdbserver/thread-db.c
Also single stepping through maybe_attach_thread() everything looks
alright, though still the threads don't show up on the GDB side.
Also, on the gdb side of things, it doesn't look like there are any
events happening .. thus handle_inferior_event() is never stepped into
at thread creation/running/exit time. Although td_thr_event_enable()
still returns TD_OK.
I'm still a bit unsure as to the code flow for most of this, so I
suppose more debugging is in order..
Notably, if I connect gdb to gdbserver while gdb and gdbserver are both
running under gdb control, SIG32 issues appear again..
Regards,
--
Paul Mundt <paul.mundt@timesys.com>
TimeSys Corporation
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Gdbserver Threading Issues
2002-12-06 13:07 ` Paul Mundt
@ 2002-12-06 13:16 ` Daniel Jacobowitz
2002-12-06 13:20 ` Paul Mundt
0 siblings, 1 reply; 12+ messages in thread
From: Daniel Jacobowitz @ 2002-12-06 13:16 UTC (permalink / raw)
To: Paul Mundt; +Cc: gdb
On Fri, Dec 06, 2002 at 05:11:54PM -0500, Paul Mundt wrote:
> On Fri, 2002-12-06 at 14:28, Daniel Jacobowitz wrote:
> > Not without more information. Look at the remote session transcript,
> > see what is going on.
>
> Hum, still debugging this .. I'm still at a loss as to why breakpoints
> would be having any effect on anything, though from the looks of it the
> newly created threads are tracked just fine by
> thread_db_find_new_threads() in gdbserver/thread-db.c
>
> Also single stepping through maybe_attach_thread() everything looks
> alright, though still the threads don't show up on the GDB side.
Thread events aren't reported immediately for latency reasons; but they
should all be delivered the first time the child stops...
> Also, on the gdb side of things, it doesn't look like there are any
> events happening .. thus handle_inferior_event() is never stepped into
> at thread creation/running/exit time. Although td_thr_event_enable()
> still returns TD_OK.
Wait, what's going on? Are you saying td_thr_event_enable is being
called on your host GDB? That's not going to work right.
> Notably, if I connect gdb to gdbserver while gdb and gdbserver are both
> running under gdb control, SIG32 issues appear again..
gdbserver may get a SIG32 while debugging; set the process debugging
gdbserver to "nostop noprint pass" that signal. Ditto SIG33, I think.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Gdbserver Threading Issues
2002-12-06 13:16 ` Daniel Jacobowitz
@ 2002-12-06 13:20 ` Paul Mundt
2002-12-06 13:23 ` Daniel Jacobowitz
0 siblings, 1 reply; 12+ messages in thread
From: Paul Mundt @ 2002-12-06 13:20 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]
On Fri, 2002-12-06 at 16:17, Daniel Jacobowitz wrote:
> Thread events aren't reported immediately for latency reasons; but they
> should all be delivered the first time the child stops...
>
Even after the threads are all finished, I don't see anything stepping
into handle_inferior_event() other then when the initial manager thread
is created.
> > Also, on the gdb side of things, it doesn't look like there are any
> > events happening .. thus handle_inferior_event() is never stepped into
> > at thread creation/running/exit time. Although td_thr_event_enable()
> > still returns TD_OK.
>
> Wait, what's going on? Are you saying td_thr_event_enable is being
> called on your host GDB? That's not going to work right.
>
I meant handle_inferior_event() on host gdb and td_thr_event_enable()
being invoked from maybe_attach_thread() on the gdbserver side.
> > Notably, if I connect gdb to gdbserver while gdb and gdbserver are both
> > running under gdb control, SIG32 issues appear again..
>
> gdbserver may get a SIG32 while debugging; set the process debugging
> gdbserver to "nostop noprint pass" that signal. Ditto SIG33, I think.
Doing that already as a workaround, wasn't positive if this was expected
or not.
Regards,
--
Paul Mundt <paul.mundt@timesys.com>
TimeSys Corporation
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Gdbserver Threading Issues
2002-12-06 13:20 ` Paul Mundt
@ 2002-12-06 13:23 ` Daniel Jacobowitz
2002-12-06 13:33 ` Paul Mundt
2002-12-06 13:59 ` Paul Mundt
0 siblings, 2 replies; 12+ messages in thread
From: Daniel Jacobowitz @ 2002-12-06 13:23 UTC (permalink / raw)
To: Paul Mundt; +Cc: gdb
On Fri, Dec 06, 2002 at 05:24:28PM -0500, Paul Mundt wrote:
> On Fri, 2002-12-06 at 16:17, Daniel Jacobowitz wrote:
> > Thread events aren't reported immediately for latency reasons; but they
> > should all be delivered the first time the child stops...
> >
> Even after the threads are all finished, I don't see anything stepping
> into handle_inferior_event() other then when the initial manager thread
> is created.
Look at set remote debug 1. What's going on?
>
> > > Also, on the gdb side of things, it doesn't look like there are any
> > > events happening .. thus handle_inferior_event() is never stepped into
> > > at thread creation/running/exit time. Although td_thr_event_enable()
> > > still returns TD_OK.
> >
> > Wait, what's going on? Are you saying td_thr_event_enable is being
> > called on your host GDB? That's not going to work right.
> >
> I meant handle_inferior_event() on host gdb and td_thr_event_enable()
> being invoked from maybe_attach_thread() on the gdbserver side.
>
> > > Notably, if I connect gdb to gdbserver while gdb and gdbserver are both
> > > running under gdb control, SIG32 issues appear again..
> >
> > gdbserver may get a SIG32 while debugging; set the process debugging
> > gdbserver to "nostop noprint pass" that signal. Ditto SIG33, I think.
>
> Doing that already as a workaround, wasn't positive if this was expected
> or not.
>
> Regards,
>
> --
> Paul Mundt <paul.mundt@timesys.com>
> TimeSys Corporation
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Gdbserver Threading Issues
2002-12-06 13:23 ` Daniel Jacobowitz
@ 2002-12-06 13:33 ` Paul Mundt
2002-12-06 13:35 ` Daniel Jacobowitz
2002-12-06 13:59 ` Paul Mundt
1 sibling, 1 reply; 12+ messages in thread
From: Paul Mundt @ 2002-12-06 13:33 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]
On Fri, 2002-12-06 at 16:23, Daniel Jacobowitz wrote:
> Look at set remote debug 1. What's going on?
>
My gdb doesn't seem to have that option:
(gdb) set remote debug 1
Undefined set remote command: "debug 1". Try "help set remote".
(gdb) help set remote
Remote protocol specific variables
Configure various remote-protocol specific variables such as
the packets being used
List of set remote subcommands:
set remote P-packet -- Set use of remote protocol `P' (set-register)
packet
set remote X-packet -- Set use of remote protocol `X' (binary-download)
packet
set remote Z-packet -- Set use of remote protocol `Z' packets
set remote access-watchpoint-packet -- Set use of remote protocol `Z4'
(access-watchpoint) packet
set remote binary-download-packet -- Set use of remote protocol `X'
(binary-download) packet
set remote hardware-breakpoint-packet -- Set use of remote protocol `Z1'
(hardware-breakpoint) packet
set remote memory-read-packet-size -- Set the maximum number of bytes
per memory-read packet
set remote memory-write-packet-size -- Set the maximum number of bytes
per memory-write packet
set remote read-watchpoint-packet -- Set use of remote protocol `Z3'
(read-watchpoint) packet
set remote set-register-packet -- Set use of remote protocol `P'
(set-register) packet
set remote software-breakpoint-packet -- Set use of remote protocol `Z0'
(software-breakpoint) packet
set remote step-over-range-packet -- Set use of remote protocol `e'
(step-over-range) packet
set remote step-over-range-w-signal-packet -- Set use of remote protocol
`E' (step-over-range-w-signal) packet
set remote symbol-lookup-packet -- Set use of remote protocol `qSymbol'
(symbol-lookup) packet
set remote write-watchpoint-packet -- Set use of remote protocol `Z2'
(write-watchpoint) packet
Type "help set remote" followed by set remote subcommand name for full
documentation.
Is there a build option I need turned on to use this?
Regards,
--
Paul Mundt <paul.mundt@timesys.com>
TimeSys Corporation
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Gdbserver Threading Issues
2002-12-06 13:33 ` Paul Mundt
@ 2002-12-06 13:35 ` Daniel Jacobowitz
0 siblings, 0 replies; 12+ messages in thread
From: Daniel Jacobowitz @ 2002-12-06 13:35 UTC (permalink / raw)
To: Paul Mundt; +Cc: gdb
On Fri, Dec 06, 2002 at 05:37:43PM -0500, Paul Mundt wrote:
> On Fri, 2002-12-06 at 16:23, Daniel Jacobowitz wrote:
> > Look at set remote debug 1. What's going on?
> >
> My gdb doesn't seem to have that option:
>
> (gdb) set remote debug 1
> Undefined set remote command: "debug 1". Try "help set remote".
>
> (gdb) help set remote
> Remote protocol specific variables
> Configure various remote-protocol specific variables such as
> the packets being used
>
> List of set remote subcommands:
>
> set remote P-packet -- Set use of remote protocol `P' (set-register)
> packet
> set remote X-packet -- Set use of remote protocol `X' (binary-download)
> packet
> set remote Z-packet -- Set use of remote protocol `Z' packets
> set remote access-watchpoint-packet -- Set use of remote protocol `Z4'
> (access-watchpoint) packet
> set remote binary-download-packet -- Set use of remote protocol `X'
> (binary-download) packet
> set remote hardware-breakpoint-packet -- Set use of remote protocol `Z1'
> (hardware-breakpoint) packet
> set remote memory-read-packet-size -- Set the maximum number of bytes
> per memory-read packet
> set remote memory-write-packet-size -- Set the maximum number of bytes
> per memory-write packet
> set remote read-watchpoint-packet -- Set use of remote protocol `Z3'
> (read-watchpoint) packet
> set remote set-register-packet -- Set use of remote protocol `P'
> (set-register) packet
> set remote software-breakpoint-packet -- Set use of remote protocol `Z0'
> (software-breakpoint) packet
> set remote step-over-range-packet -- Set use of remote protocol `e'
> (step-over-range) packet
> set remote step-over-range-w-signal-packet -- Set use of remote protocol
> `E' (step-over-range-w-signal) packet
> set remote symbol-lookup-packet -- Set use of remote protocol `qSymbol'
> (symbol-lookup) packet
> set remote write-watchpoint-packet -- Set use of remote protocol `Z2'
> (write-watchpoint) packet
>
> Type "help set remote" followed by set remote subcommand name for full
> documentation.
>
> Is there a build option I need turned on to use this?
Sorry. Set debug remote 1.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Gdbserver Threading Issues
2002-12-06 13:23 ` Daniel Jacobowitz
2002-12-06 13:33 ` Paul Mundt
@ 2002-12-06 13:59 ` Paul Mundt
2002-12-06 14:08 ` Daniel Jacobowitz
1 sibling, 1 reply; 12+ messages in thread
From: Paul Mundt @ 2002-12-06 13:59 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
[-- Attachment #1.1: Type: text/plain, Size: 414 bytes --]
On Fri, 2002-12-06 at 16:23, Daniel Jacobowitz wrote:
> > Even after the threads are all finished, I don't see anything stepping
> > into handle_inferior_event() other then when the initial manager thread
> > is created.
>
> Look at set remote debug 1. What's going on?
>
The log with remote debugging turned on is attached..
Regards,
--
Paul Mundt <paul.mundt@timesys.com>
TimeSys Corporation
[-- Attachment #1.2: remote-debug.log --]
[-- Type: text/plain, Size: 18084 bytes --]
(gdb) target remote localhost:2345
Remote debugging using localhost:2345
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: T0505:00000000;04:b0f6ffbf;08:101e0040;
Sending packet: $m40001e10,8#8c...Ack
Packet received: 54e8460000005b89
Sending packet: $m40001e10,7#8b...Ack
Packet received: 54e8460000005b
0x40001e10 in ?? ()
Sending packet: $m804987c,d0#d4...Ack
Packet received: 0100000010000000010000004b0000000c000000f08304080d000000308704080400000028810408050000004082040806000000708104080a000000be0000000b00000010000000150000000000000003000000449804080200000050000000140000001100000017000000a0830408110000009883040812000000080000001300000008000000feffff6f38830408ffffff6f02000000f0ffff6f1e830408000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
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)
(gdb) c
Continuing.
Sending packet: $Z0,4000d61c,1#05...Ack
Packet received:
Packet Z0 (software-breakpoint) is NOT supported
Sending packet: $m4000d61c,1#bc...Ack
Packet received: 55
Sending packet: $X4000d61c,0:#e0...Ack
Packet received:
binary downloading NOT suppported by target
Sending packet: $M4000d61c,1:cc#9c...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack
Packet received: T0505:44f1ffbf;04:78efffbf;08:1dd60040;
Sending packet: $Hg0#df...Ack
Packet received: OK
Sending packet: $g#67...Ack
Packet received: 00000000000000000c5f01409858014078efffbf44f1ffbf805c0140f85e01401dd6004046020000230000002b0000002b0000002b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000400000000000000000000074d145175d74d185004000000000000000c000407f03000000000000ffff000023000000807128402b000000387c2940e9020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ffffffff
Sending packet: $P8=1cd60040#b7...Ack
Packet received:
Sending packet: $G00000000000000000c5f01409858014078efffbf44f1ffbf805c0140f85e01401cd6004046020000230000002b0000002b0000002b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000400000000000000000000074d145175d74d185004000000000000000c000407f03000000000000ffff000023000000807128402b000000387c2940e9020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ffffffff#f0...Ack
Packet received: OK
Sending packet: $M4000d61c,1:55#40...Ack
Packet received: OK
Sending packet: $m804987c,d0#d4...Ack
Packet received: 0100000010000000010000004b0000000c000000f08304080d000000308704080400000028810408050000004082040806000000708104080a000000be0000000b00000010000000150000000c5f014003000000449804080200000050000000140000001100000017000000a0830408110000009883040812000000080000001300000008000000feffff6f38830408ffffff6f02000000f0ffff6f1e830408000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Sending packet: $m40015f10,4#8e...Ack
Packet received: 385f0140
Sending packet: $m40015f38,14#c9...Ack
Packet received: 00000000cf2b01407c9804082864014000000000
Sending packet: $m40016428,14#97...Ack
Packet received: 004002401064014028a1034078660140385f0140
Sending packet: $m40016410,4#5d...Ack
Packet received: 2f6c6962
Sending packet: $m40016414,4#61...Ack
Packet received: 2f6c6962
Sending packet: $m40016418,4#65...Ack
Packet received: 70746872
Sending packet: $m4001641c,4#90...Ack
Packet received: 6561642e
Sending packet: $m40016420,4#5e...Ack
Packet received: 736f2e30
Sending packet: $m40016424,4#62...Ack
Packet received: 00000000
Sending packet: $m40016678,14#9e...Ack
Packet received: 00b003406866014038c31640805c014028640140
Sending packet: $m40016668,4#6c...Ack
Packet received: 2f6c6962
Sending packet: $m4001666c,4#97...Ack
Packet received: 2f6c6962
Sending packet: $m40016670,4#65...Ack
Packet received: 632e736f
Sending packet: $m40016674,4#69...Ack
Packet received: 2e360000
Sending packet: $m40015c80,14#c3...Ack
Packet received: 00000040f48004081c5a01400000000078660140
Sending packet: $m80480f4,4#6b...Ack
Packet received: 2f6c6962
Sending packet: $m80480f8,4#6f...Ack
Packet received: 2f6c642d
Sending packet: $m80480fc,4#9a...Ack
Packet received: 6c696e75
Sending packet: $m8048100,4#32...Ack
Packet received: 782e736f
Sending packet: $m8048104,4#36...Ack
Packet received: 2e320000
Sending packet: $qSymbol::#5b...Ack
Packet received: qSymbol:5f5f707468726561645f746872656164735f6576656e7473
Sending packet: $qSymbol:4003a248:5f5f707468726561645f746872656164735f6576656e7473#0d...Ack
Packet received: qSymbol:5f5f707468726561645f6c6173745f6576656e74
Sending packet: $qSymbol:4003a250:5f5f707468726561645f6c6173745f6576656e74#89...Ack
Packet received: qSymbol:5f5f707468726561645f68616e646c65735f6e756d
Sending packet: $qSymbol:40037520:5f5f707468726561645f68616e646c65735f6e756d#2a...Ack
Packet received: qSymbol:5f5f707468726561645f68616e646c6573
Sending packet: $qSymbol:40033520:5f5f707468726561645f68616e646c6573#ea...Ack
Packet received: qSymbol:707468726561645f6b657973
Sending packet: $qSymbol:40037ec0:707468726561645f6b657973#ae...Ack
Packet received: qSymbol:5f5f6c696e7578746872656164735f707468726561645f746872656164735f6d6178
Sending packet: $qSymbol:4003248c:5f5f6c696e7578746872656164735f707468726561645f746872656164735f6d6178#cd...Ack
Packet received: qSymbol:5f5f6c696e7578746872656164735f707468726561645f6b6579735f6d6178
Sending packet: $qSymbol:400324ac:5f5f6c696e7578746872656164735f707468726561645f6b6579735f6d6178#eb...Ack
Packet received: qSymbol:5f5f6c696e7578746872656164735f707468726561645f73697a656f665f6465736372
Sending packet: $qSymbol::5f5f6c696e7578746872656164735f707468726561645f73697a656f665f6465736372#a2...Ack
Packet received: qSymbol:5f5f6c696e7578746872656164735f6372656174655f6576656e74
Sending packet: $qSymbol:40032134:5f5f6c696e7578746872656164735f6372656174655f6576656e74#81...Ack
Packet received: OK
Sending packet: $qSymbol::#5b...Ack
Packet received: OK
Sending packet: $qSymbol::#5b...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $s#73...Ack
Packet received: T0505:44f1ffbf;04:74efffbf;08:1dd60040;thread:400;
[New Thread 1024]
Sending packet: $g#67...Ack
Packet received: 00000000000000000c5f01409858014074efffbf44f1ffbf805c0140f85e01401dd6004046030000230000002b0000002b0000002b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000400000000000000000000074d145175d74d185004000000000000000c000407f03000000000000ffff000023000000807128402b000000387c2940e9020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ffffffff
Sending packet: $m4000d61c,1#bc...Ack
Packet received: 55
Sending packet: $M4000d61c,1:cc#9c...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack
Packet received: T0505:a4f6ffbf;04:68f6ffbf;08:1dd60040;
Sending packet: $g#67...Ack
Packet received: 0c5f01401cd600400c5f01409858014068f6ffbfa4f6ffbf28640140106401401dd6004002020000230000002b0000002b0000002b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000400000000000000000000074d145175d74d185004000000000000000c000407f03000000000000ffff000023000000807128402b000000387c2940e9020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ffffffff
Sending packet: $G0c5f01401cd600400c5f01409858014068f6ffbfa4f6ffbf28640140106401401cd6004002020000230000002b0000002b0000002b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000400000000000000000000074d145175d74d185004000000000000000c000407f03000000000000ffff000023000000807128402b000000387c2940e9020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ffffffff#36...Ack
Packet received: OK
Sending packet: $M4000d61c,1:55#40...Ack
Packet received: OK
Sending packet: $m40015f10,4#8e...Ack
Packet received: 385f0140
Sending packet: $m40015f38,14#c9...Ack
Packet received: 00000000cf2b01407c9804082864014000000000
Sending packet: $m40016428,14#97...Ack
Packet received: 004002401064014028a1034078660140385f0140
Sending packet: $m40016410,4#5d...Ack
Packet received: 2f6c6962
Sending packet: $m40016414,4#61...Ack
Packet received: 2f6c6962
Sending packet: $m40016418,4#65...Ack
Packet received: 70746872
Sending packet: $m4001641c,4#90...Ack
Packet received: 6561642e
Sending packet: $m40016420,4#5e...Ack
Packet received: 736f2e30
Sending packet: $m40016424,4#62...Ack
Packet received: 00000000
Sending packet: $m40016678,14#9e...Ack
Packet received: 00b003406866014038c31640805c014028640140
Sending packet: $m40016668,4#6c...Ack
Packet received: 2f6c6962
Sending packet: $m4001666c,4#97...Ack
Packet received: 2f6c6962
Sending packet: $m40016670,4#65...Ack
Packet received: 632e736f
Sending packet: $m40016674,4#69...Ack
Packet received: 2e360000
Sending packet: $m40015c80,14#c3...Ack
Packet received: 00000040f48004081c5a01400000000078660140
Sending packet: $m80480f4,4#6b...Ack
Packet received: 2f6c6962
Sending packet: $m80480f8,4#6f...Ack
Packet received: 2f6c642d
Sending packet: $m80480fc,4#9a...Ack
Packet received: 6c696e75
Sending packet: $m8048100,4#32...Ack
Packet received: 782e736f
Sending packet: $m8048104,4#36...Ack
Packet received: 2e320000
Sending packet: $Hc400#3f...Ack
Packet received: OK
Sending packet: $s#73...Ack
Packet received: T0505:a4f6ffbf;04:64f6ffbf;08:1dd60040;
Sending packet: $m4000d61c,1#bc...Ack
Packet received: 55
Sending packet: $M4000d61c,1:cc#9c...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack
Packet received: T0505:a4f6ffbf;04:68f6ffbf;08:1dd60040;
Sending packet: $g#67...Ack
Packet received: 0c5f0140cf2b0140000000009858014068f6ffbfa4f6ffbf385f0140000000001dd6004046020000230000002b0000002b0000002b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000400000000000000000000074d145175d74d185004000000000000000c000407f03000000000000ffff000023000000807128402b000000387c2940e9020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ffffffff
Sending packet: $G0c5f0140cf2b0140000000009858014068f6ffbfa4f6ffbf385f0140000000001cd6004046020000230000002b0000002b0000002b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000400000000000000000000074d145175d74d185004000000000000000c000407f03000000000000ffff000023000000807128402b000000387c2940e9020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ffffffff#1d...Ack
Packet received: OK
Sending packet: $M4000d61c,1:55#40...Ack
Packet received: OK
Sending packet: $m40015f10,4#8e...Ack
Packet received: 385f0140
Sending packet: $m40015f38,14#c9...Ack
Packet received: 00000000cf2b01407c9804082864014000000000
Sending packet: $m40016428,14#97...Ack
Packet received: 004002401064014028a1034078660140385f0140
Sending packet: $m40016410,4#5d...Ack
Packet received: 2f6c6962
Sending packet: $m40016414,4#61...Ack
Packet received: 2f6c6962
Sending packet: $m40016418,4#65...Ack
Packet received: 70746872
Sending packet: $m4001641c,4#90...Ack
Packet received: 6561642e
Sending packet: $m40016420,4#5e...Ack
Packet received: 736f2e30
Sending packet: $m40016424,4#62...Ack
Packet received: 00000000
Sending packet: $m40016678,14#9e...Ack
Packet received: 00b003406866014038c31640805c014028640140
Sending packet: $m40016668,4#6c...Ack
Packet received: 2f6c6962
Sending packet: $m4001666c,4#97...Ack
Packet received: 2f6c6962
Sending packet: $m40016670,4#65...Ack
Packet received: 632e736f
Sending packet: $m40016674,4#69...Ack
Packet received: 2e360000
Sending packet: $m40015c80,14#c3...Ack
Packet received: 00000040f48004081c5a01400000000078660140
Sending packet: $m80480f4,4#6b...Ack
Packet received: 2f6c6962
Sending packet: $m80480f8,4#6f...Ack
Packet received: 2f6c642d
Sending packet: $m80480fc,4#9a...Ack
Packet received: 6c696e75
Sending packet: $m8048100,4#32...Ack
Packet received: 782e736f
Sending packet: $m8048104,4#36...Ack
Packet received: 2e320000
Sending packet: $Hc400#3f...Ack
Packet received: OK
Sending packet: $s#73...Ack
Packet received: T0505:a4f6ffbf;04:64f6ffbf;08:1dd60040;
Sending packet: $m4000d61c,1#bc...Ack
Packet received: 55
Sending packet: $M4000d61c,1:cc#9c...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack
Packet received: T0505:a4f6ffbf;04:68f6ffbf;08:1dd60040;
Sending packet: $g#67...Ack
Packet received: 0c5f0140cf2b0140000000009858014068f6ffbfa4f6ffbf385f0140000000001dd6004046020000230000002b0000002b0000002b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000400000000000000000000074d145175d74d185004000000000000000c000407f03000000000000ffff000023000000807128402b000000387c2940e9020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ffffffff
Sending packet: $G0c5f0140cf2b0140000000009858014068f6ffbfa4f6ffbf385f0140000000001cd6004046020000230000002b0000002b0000002b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000400000000000000000000074d145175d74d185004000000000000000c000407f03000000000000ffff000023000000807128402b000000387c2940e9020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ffffffff#1d...Ack
Packet received: OK
Sending packet: $M4000d61c,1:55#40...Ack
Packet received: OK
Sending packet: $m40015f10,4#8e...Ack
Packet received: 385f0140
Sending packet: $m40015f38,14#c9...Ack
Packet received: 00000000cf2b01407c9804082864014000000000
Sending packet: $m40016428,14#97...Ack
Packet received: 004002401064014028a1034078660140385f0140
Sending packet: $m40016410,4#5d...Ack
Packet received: 2f6c6962
Sending packet: $m40016414,4#61...Ack
Packet received: 2f6c6962
Sending packet: $m40016418,4#65...Ack
Packet received: 70746872
Sending packet: $m4001641c,4#90...Ack
Packet received: 6561642e
Sending packet: $m40016420,4#5e...Ack
Packet received: 736f2e30
Sending packet: $m40016424,4#62...Ack
Packet received: 00000000
Sending packet: $m40016678,14#9e...Ack
Packet received: 00b003406866014038c31640805c014028640140
Sending packet: $m40016668,4#6c...Ack
Packet received: 2f6c6962
Sending packet: $m4001666c,4#97...Ack
Attaching to thread 2049 (LWP 1912)
Attaching to thread 1026 (LWP 1913)
created thread 0
Starting thread 1
Starting real thread 0
Attaching to thread 2051 (LWP 1914)
created thread 1
Starting real thread 1
Ending thread
Ending thread
Packet received: 2f6c6962
Sending packet: $m40016670,4#65...Ack
Packet received: 632e736f
Sending packet: $m40016674,4#69...Ack
Packet received: 2e360000
Sending packet: $m40015c80,14#c3...Ack
Packet received: 00000040f48004081c5a01400000000078660140
Sending packet: $m80480f4,4#6b...Ack
Packet received: 2f6c6962
Sending packet: $m80480f8,4#6f...Ack
Packet received: 2f6c642d
Sending packet: $m80480fc,4#9a...Ack
Packet received: 6c696e75
Sending packet: $m8048100,4#32...Ack
Packet received: 782e736f
Sending packet: $m8048104,4#36...Ack
Packet received: 2e320000
Sending packet: $Hc400#3f...Ack
Packet received: OK
Sending packet: $s#73...Ack
Packet received: T0505:a4f6ffbf;04:64f6ffbf;08:1dd60040;
Sending packet: $m4000d61c,1#bc...Ack
Packet received: 55
Sending packet: $M4000d61c,1:cc#9c...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack
Packet received: T1405:b8f4ffbf;04:d0f1ffbf;08:c4df0240;
Sending packet: $C14#a8...Ack
Packet received: W02
Program exited with code 02.
(gdb)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Gdbserver Threading Issues
2002-12-06 13:59 ` Paul Mundt
@ 2002-12-06 14:08 ` Daniel Jacobowitz
2002-12-06 14:15 ` Paul Mundt
0 siblings, 1 reply; 12+ messages in thread
From: Daniel Jacobowitz @ 2002-12-06 14:08 UTC (permalink / raw)
To: Paul Mundt; +Cc: gdb
On Fri, Dec 06, 2002 at 06:03:38PM -0500, Paul Mundt wrote:
> On Fri, 2002-12-06 at 16:23, Daniel Jacobowitz wrote:
> > > Even after the threads are all finished, I don't see anything stepping
> > > into handle_inferior_event() other then when the initial manager thread
> > > is created.
> >
> > Look at set remote debug 1. What's going on?
> >
> The log with remote debugging turned on is attached..
So: what are you doing in GDB to get this log; what is happening; what
do you expect to happen? I don't see an obvious problem.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Gdbserver Threading Issues
2002-12-06 14:08 ` Daniel Jacobowitz
@ 2002-12-06 14:15 ` Paul Mundt
2002-12-06 17:15 ` Daniel Jacobowitz
0 siblings, 1 reply; 12+ messages in thread
From: Paul Mundt @ 2002-12-06 14:15 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]
On Fri, 2002-12-06 at 17:09, Daniel Jacobowitz wrote:
> > The log with remote debugging turned on is attached..
>
> So: what are you doing in GDB to get this log; what is happening; what
> do you expect to happen? I don't see an obvious problem.
Same thing as what I explained in my intial post.
The test app starts up and spawns some arbitrary number of threads,
which in turn sleep for a bit and then return.. in this case, 2 threads.
When running this test app under gdbserver, the only thread being
reported to gdb is the manager thread.. (ie, [New thread x (LWP y)]).
Because of this, I can't do 'info threads' and see anything other then
the manager thread .. and thus can't really do any thread-specific
debugging.
If I run natively, this isn't an issue.
If I insert a breakpoint in the function being run by the threads, then
everything comes up fine. Then I can break after the threads are created
and do per-thread debugging without any issues.. but only if I place a
breakpoint there.
If this isn't clear enough, I can toss together a brief log of what I'm
doing.
Regards,
--
Paul Mundt <paul.mundt@timesys.com>
TimeSys Corporation
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Gdbserver Threading Issues
2002-12-06 14:15 ` Paul Mundt
@ 2002-12-06 17:15 ` Daniel Jacobowitz
0 siblings, 0 replies; 12+ messages in thread
From: Daniel Jacobowitz @ 2002-12-06 17:15 UTC (permalink / raw)
To: Paul Mundt; +Cc: gdb
On Fri, Dec 06, 2002 at 06:20:00PM -0500, Paul Mundt wrote:
> On Fri, 2002-12-06 at 17:09, Daniel Jacobowitz wrote:
> > > The log with remote debugging turned on is attached..
> >
> > So: what are you doing in GDB to get this log; what is happening; what
> > do you expect to happen? I don't see an obvious problem.
>
> Same thing as what I explained in my intial post.
>
> The test app starts up and spawns some arbitrary number of threads,
> which in turn sleep for a bit and then return.. in this case, 2 threads.
>
> When running this test app under gdbserver, the only thread being
> reported to gdb is the manager thread.. (ie, [New thread x (LWP y)]).
>
> Because of this, I can't do 'info threads' and see anything other then
> the manager thread .. and thus can't really do any thread-specific
> debugging.
Actually it's the _initial_ thread, not the manager thread, most
likely.
> If I run natively, this isn't an issue.
>
> If I insert a breakpoint in the function being run by the threads, then
> everything comes up fine. Then I can break after the threads are created
> and do per-thread debugging without any issues.. but only if I place a
> breakpoint there.
>
> If this isn't clear enough, I can toss together a brief log of what I'm
> doing.
You won't get [New thread x (LWP y)] messages at thread creation time
if you're using gdbserver; you'll get them when you stop for some other
reason and do info threads, generally. If you never stop the running
application you won't see them.
But are you stopping the application some other way and not having
threads show up? A precise example session would be appreciated.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2002-12-07 1:15 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-06 11:20 Gdbserver Threading Issues Paul Mundt
2002-12-06 11:28 ` Daniel Jacobowitz
2002-12-06 13:07 ` Paul Mundt
2002-12-06 13:16 ` Daniel Jacobowitz
2002-12-06 13:20 ` Paul Mundt
2002-12-06 13:23 ` Daniel Jacobowitz
2002-12-06 13:33 ` Paul Mundt
2002-12-06 13:35 ` Daniel Jacobowitz
2002-12-06 13:59 ` Paul Mundt
2002-12-06 14:08 ` Daniel Jacobowitz
2002-12-06 14:15 ` Paul Mundt
2002-12-06 17:15 ` Daniel Jacobowitz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox