* 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