* Problems interrupting remote target on powerpc @ 2023-04-27 4:55 Chris Packham 2023-04-28 9:14 ` Chris Packham 0 siblings, 1 reply; 12+ messages in thread From: Chris Packham @ 2023-04-27 4:55 UTC (permalink / raw) To: GDB Mailing list Hi GDB, I've had a few users report to me issues with interrupting a running process after continuing when attached to a remote gdbserver running on a powerpc target. Everything seems to work properly on arm and aarch64 so there might be some powerpc or big-endian specific issue lurking. The gdbserver version we're currently using is from gdb-11.2 built from source and most users have gdb-multiarch 12.1 from ubuntu 22.04 (some might still be using gdb-multiarch 10.2 from a PPA). Does this ring any bells for anyone? I'm going to try and get hold of a powerpc target to test with to see if I can reproduce it for myself. Thanks, Chris ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problems interrupting remote target on powerpc 2023-04-27 4:55 Problems interrupting remote target on powerpc Chris Packham @ 2023-04-28 9:14 ` Chris Packham 2023-04-28 9:18 ` Luis Machado 0 siblings, 1 reply; 12+ messages in thread From: Chris Packham @ 2023-04-28 9:14 UTC (permalink / raw) To: GDB Mailing list [-- Attachment #1: Type: text/plain, Size: 1111 bytes --] On Thu, 27 Apr 2023, 4:55 PM Chris Packham, <judge.packham@gmail.com> wrote: > Hi GDB, > > I've had a few users report to me issues with interrupting a running > process after continuing when attached to a remote gdbserver running > on a powerpc target. Everything seems to work properly on arm and > aarch64 so there might be some powerpc or big-endian specific issue > lurking. > > The gdbserver version we're currently using is from gdb-11.2 built > from source and most users have gdb-multiarch 12.1 from ubuntu 22.04 > (some might still be using gdb-multiarch 10.2 from a PPA). > > Does this ring any bells for anyone? I'm going to try and get hold of > a powerpc target to test with to see if I can reproduce it for myself. > > Thanks, > Chris > Did some digging of my own I can report that indeed things aren't working well for powerpc. I tried updating gdbserver to 12.1 and 13.1. 12.1 was much the same as 11.2. 13.1 reported that it was unable to send sigkill when processing the interrupt command. 13.1 also seems not to be able to respond to the 'info os processes' command from the gdb client > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problems interrupting remote target on powerpc 2023-04-28 9:14 ` Chris Packham @ 2023-04-28 9:18 ` Luis Machado 2023-04-28 9:38 ` Chris Packham 0 siblings, 1 reply; 12+ messages in thread From: Luis Machado @ 2023-04-28 9:18 UTC (permalink / raw) To: Chris Packham, GDB Mailing list On 4/28/23 10:14, Chris Packham via Gdb wrote: > On Thu, 27 Apr 2023, 4:55 PM Chris Packham, <judge.packham@gmail.com> wrote: > >> Hi GDB, >> >> I've had a few users report to me issues with interrupting a running >> process after continuing when attached to a remote gdbserver running >> on a powerpc target. Everything seems to work properly on arm and >> aarch64 so there might be some powerpc or big-endian specific issue >> lurking. >> >> The gdbserver version we're currently using is from gdb-11.2 built >> from source and most users have gdb-multiarch 12.1 from ubuntu 22.04 >> (some might still be using gdb-multiarch 10.2 from a PPA). >> >> Does this ring any bells for anyone? I'm going to try and get hold of >> a powerpc target to test with to see if I can reproduce it for myself. >> >> Thanks, >> Chris >> > > Did some digging of my own I can report that indeed things aren't working > well for powerpc. I tried updating gdbserver to 12.1 and 13.1. 12.1 was > much the same as 11.2. 13.1 reported that it was unable to send sigkill > when processing the interrupt command. 13.1 also seems not to be able to > respond to the 'info os processes' command from the gdb client > >> What sort of behavior/output do you see? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problems interrupting remote target on powerpc 2023-04-28 9:18 ` Luis Machado @ 2023-04-28 9:38 ` Chris Packham 2023-04-28 9:40 ` Luis Machado 0 siblings, 1 reply; 12+ messages in thread From: Chris Packham @ 2023-04-28 9:38 UTC (permalink / raw) To: Luis Machado; +Cc: GDB Mailing list [-- Attachment #1: Type: text/plain, Size: 1514 bytes --] On Fri, 28 Apr 2023, 9:19 PM Luis Machado, <luis.machado@arm.com> wrote: > On 4/28/23 10:14, Chris Packham via Gdb wrote: > > On Thu, 27 Apr 2023, 4:55 PM Chris Packham, <judge.packham@gmail.com> > wrote: > > > >> Hi GDB, > >> > >> I've had a few users report to me issues with interrupting a running > >> process after continuing when attached to a remote gdbserver running > >> on a powerpc target. Everything seems to work properly on arm and > >> aarch64 so there might be some powerpc or big-endian specific issue > >> lurking. > >> > >> The gdbserver version we're currently using is from gdb-11.2 built > >> from source and most users have gdb-multiarch 12.1 from ubuntu 22.04 > >> (some might still be using gdb-multiarch 10.2 from a PPA). > >> > >> Does this ring any bells for anyone? I'm going to try and get hold of > >> a powerpc target to test with to see if I can reproduce it for myself. > >> > >> Thanks, > >> Chris > >> > > > > Did some digging of my own I can report that indeed things aren't working > > well for powerpc. I tried updating gdbserver to 12.1 and 13.1. 12.1 was > > much the same as 11.2. 13.1 reported that it was unable to send sigkill > > when processing the interrupt command. 13.1 also seems not to be able to > > respond to the 'info os processes' command from the gdb client > > > >> > > What sort of behavior/output do you see? > I'll capture some proper output when I'm back in the office but basically once I 'continue' I can't get the gdb prompt back with Ctrl+C. > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problems interrupting remote target on powerpc 2023-04-28 9:38 ` Chris Packham @ 2023-04-28 9:40 ` Luis Machado 2023-04-28 11:25 ` Chris Packham 0 siblings, 1 reply; 12+ messages in thread From: Luis Machado @ 2023-04-28 9:40 UTC (permalink / raw) To: Chris Packham; +Cc: GDB Mailing list On 4/28/23 10:38, Chris Packham wrote: > > > On Fri, 28 Apr 2023, 9:19 PM Luis Machado, <luis.machado@arm.com <mailto:luis.machado@arm.com>> wrote: > > On 4/28/23 10:14, Chris Packham via Gdb wrote: > > On Thu, 27 Apr 2023, 4:55 PM Chris Packham, <judge.packham@gmail.com <mailto:judge.packham@gmail.com>> wrote: > > > >> Hi GDB, > >> > >> I've had a few users report to me issues with interrupting a running > >> process after continuing when attached to a remote gdbserver running > >> on a powerpc target. Everything seems to work properly on arm and > >> aarch64 so there might be some powerpc or big-endian specific issue > >> lurking. > >> > >> The gdbserver version we're currently using is from gdb-11.2 built > >> from source and most users have gdb-multiarch 12.1 from ubuntu 22.04 > >> (some might still be using gdb-multiarch 10.2 from a PPA). > >> > >> Does this ring any bells for anyone? I'm going to try and get hold of > >> a powerpc target to test with to see if I can reproduce it for myself. > >> > >> Thanks, > >> Chris > >> > > > > Did some digging of my own I can report that indeed things aren't working > > well for powerpc. I tried updating gdbserver to 12.1 and 13.1. 12.1 was > > much the same as 11.2. 13.1 reported that it was unable to send sigkill > > when processing the interrupt command. 13.1 also seems not to be able to > > respond to the 'info os processes' command from the gdb client > > > >> > > What sort of behavior/output do you see? > > > I'll capture some proper output when I'm back in the office but basically once I 'continue' I can't get the gdb prompt back with Ctrl+C. > Is it a tight loop by any change? Or is gdb trapped in a long sequence of instruction-steps? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problems interrupting remote target on powerpc 2023-04-28 9:40 ` Luis Machado @ 2023-04-28 11:25 ` Chris Packham 2023-04-28 13:02 ` Luis Machado 0 siblings, 1 reply; 12+ messages in thread From: Chris Packham @ 2023-04-28 11:25 UTC (permalink / raw) To: Luis Machado; +Cc: GDB Mailing list [-- Attachment #1: Type: text/plain, Size: 2279 bytes --] On Fri, 28 Apr 2023, 9:41 PM Luis Machado, <luis.machado@arm.com> wrote: > On 4/28/23 10:38, Chris Packham wrote: > > > > > > On Fri, 28 Apr 2023, 9:19 PM Luis Machado, <luis.machado@arm.com > <mailto:luis.machado@arm.com>> wrote: > > > > On 4/28/23 10:14, Chris Packham via Gdb wrote: > > > On Thu, 27 Apr 2023, 4:55 PM Chris Packham, < > judge.packham@gmail.com <mailto:judge.packham@gmail.com>> wrote: > > > > > >> Hi GDB, > > >> > > >> I've had a few users report to me issues with interrupting a > running > > >> process after continuing when attached to a remote gdbserver > running > > >> on a powerpc target. Everything seems to work properly on arm and > > >> aarch64 so there might be some powerpc or big-endian specific > issue > > >> lurking. > > >> > > >> The gdbserver version we're currently using is from gdb-11.2 > built > > >> from source and most users have gdb-multiarch 12.1 from ubuntu > 22.04 > > >> (some might still be using gdb-multiarch 10.2 from a PPA). > > >> > > >> Does this ring any bells for anyone? I'm going to try and get > hold of > > >> a powerpc target to test with to see if I can reproduce it for > myself. > > >> > > >> Thanks, > > >> Chris > > >> > > > > > > Did some digging of my own I can report that indeed things aren't > working > > > well for powerpc. I tried updating gdbserver to 12.1 and 13.1. > 12.1 was > > > much the same as 11.2. 13.1 reported that it was unable to send > sigkill > > > when processing the interrupt command. 13.1 also seems not to be > able to > > > respond to the 'info os processes' command from the gdb client > > > > > >> > > > > What sort of behavior/output do you see? > > > > > > I'll capture some proper output when I'm back in the office but > basically once I 'continue' I can't get the gdb prompt back with Ctrl+C. > > > > Is it a tight loop by any change? Or is gdb trapped in a long sequence of > instruction-steps? > It's a daemon using a g_main_loop() not sure if that counts as a tight loop. GDB shouldn't be doing any stepping. I'll also give a process that runs and finishes when I get a chance to see if there are issues with that. > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problems interrupting remote target on powerpc 2023-04-28 11:25 ` Chris Packham @ 2023-04-28 13:02 ` Luis Machado 2023-04-28 14:05 ` Joel Brobecker 2023-05-01 5:30 ` Chris Packham 0 siblings, 2 replies; 12+ messages in thread From: Luis Machado @ 2023-04-28 13:02 UTC (permalink / raw) To: Chris Packham; +Cc: GDB Mailing list On 4/28/23 12:25, Chris Packham wrote: > > > On Fri, 28 Apr 2023, 9:41 PM Luis Machado, <luis.machado@arm.com <mailto:luis.machado@arm.com>> wrote: > > On 4/28/23 10:38, Chris Packham wrote: > > > > > > On Fri, 28 Apr 2023, 9:19 PM Luis Machado, <luis.machado@arm.com <mailto:luis.machado@arm.com> <mailto:luis.machado@arm.com <mailto:luis.machado@arm.com>>> wrote: > > > > On 4/28/23 10:14, Chris Packham via Gdb wrote: > > > On Thu, 27 Apr 2023, 4:55 PM Chris Packham, <judge.packham@gmail.com <mailto:judge.packham@gmail.com> <mailto:judge.packham@gmail.com <mailto:judge.packham@gmail.com>>> wrote: > > > > > >> Hi GDB, > > >> > > >> I've had a few users report to me issues with interrupting a running > > >> process after continuing when attached to a remote gdbserver running > > >> on a powerpc target. Everything seems to work properly on arm and > > >> aarch64 so there might be some powerpc or big-endian specific issue > > >> lurking. > > >> > > >> The gdbserver version we're currently using is from gdb-11.2 built > > >> from source and most users have gdb-multiarch 12.1 from ubuntu 22.04 > > >> (some might still be using gdb-multiarch 10.2 from a PPA). > > >> > > >> Does this ring any bells for anyone? I'm going to try and get hold of > > >> a powerpc target to test with to see if I can reproduce it for myself. > > >> > > >> Thanks, > > >> Chris > > >> > > > > > > Did some digging of my own I can report that indeed things aren't working > > > well for powerpc. I tried updating gdbserver to 12.1 and 13.1. 12.1 was > > > much the same as 11.2. 13.1 reported that it was unable to send sigkill > > > when processing the interrupt command. 13.1 also seems not to be able to > > > respond to the 'info os processes' command from the gdb client > > > > > >> > > > > What sort of behavior/output do you see? > > > > > > I'll capture some proper output when I'm back in the office but basically once I 'continue' I can't get the gdb prompt back with Ctrl+C. > > > > Is it a tight loop by any change? Or is gdb trapped in a long sequence of instruction-steps? > > > It's a daemon using a g_main_loop() not sure if that counts as a tight loop. GDB shouldn't be doing any stepping. I'll also give a process that runs and finishes when I get a chance to see if there are issues with that. > Got it. It would be useful to see some of the output with "set debug remote 1" and "set debug remote-packet-max-chars -1". It may indicate what's going on. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problems interrupting remote target on powerpc 2023-04-28 13:02 ` Luis Machado @ 2023-04-28 14:05 ` Joel Brobecker 2023-05-01 5:30 ` Chris Packham 1 sibling, 0 replies; 12+ messages in thread From: Joel Brobecker @ 2023-04-28 14:05 UTC (permalink / raw) To: Luis Machado via Gdb; +Cc: Chris Packham, Joel Brobecker FWIW, the way I remember things on how it's supposed to work is the following: - The Ctrl-c sequence triggers a SIGINT - GDB has a handler and the remote layer sends a single interrupt character to GDBserver - The interrupt character arriving on the GDBserver side of the connection triggers a SIGINT in GDBserver - GDBserver has a handler that sends a SIGINT to the inferior. - The inferior receives the SIGINT, and thus stops, and the kernel informs GDBserver, and GDBserver then sends a stop packet back to GDB, who then tells the user the inferior has stopped on a SIGINT. One typically workaround when the above doesn't work is to log onto the remote machine, and send the inferior process a SIGINT signal by hand, by using the "kill -INT <PID>" command. -- Joel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problems interrupting remote target on powerpc 2023-04-28 13:02 ` Luis Machado 2023-04-28 14:05 ` Joel Brobecker @ 2023-05-01 5:30 ` Chris Packham 2023-05-01 21:20 ` Chris Packham 2023-05-02 12:55 ` Luis Machado 1 sibling, 2 replies; 12+ messages in thread From: Chris Packham @ 2023-05-01 5:30 UTC (permalink / raw) To: Luis Machado; +Cc: GDB Mailing list On Sat, Apr 29, 2023 at 1:02 AM Luis Machado <luis.machado@arm.com> wrote: > > On 4/28/23 12:25, Chris Packham wrote: > > > > > > On Fri, 28 Apr 2023, 9:41 PM Luis Machado, <luis.machado@arm.com <mailto:luis.machado@arm.com>> wrote: > > > > On 4/28/23 10:38, Chris Packham wrote: > > > > > > > > > On Fri, 28 Apr 2023, 9:19 PM Luis Machado, <luis.machado@arm.com <mailto:luis.machado@arm.com> <mailto:luis.machado@arm.com <mailto:luis.machado@arm.com>>> wrote: > > > > > > On 4/28/23 10:14, Chris Packham via Gdb wrote: > > > > On Thu, 27 Apr 2023, 4:55 PM Chris Packham, <judge.packham@gmail.com <mailto:judge.packham@gmail.com> <mailto:judge.packham@gmail.com <mailto:judge.packham@gmail.com>>> wrote: > > > > > > > >> Hi GDB, > > > >> > > > >> I've had a few users report to me issues with interrupting a running > > > >> process after continuing when attached to a remote gdbserver running > > > >> on a powerpc target. Everything seems to work properly on arm and > > > >> aarch64 so there might be some powerpc or big-endian specific issue > > > >> lurking. > > > >> > > > >> The gdbserver version we're currently using is from gdb-11.2 built > > > >> from source and most users have gdb-multiarch 12.1 from ubuntu 22.04 > > > >> (some might still be using gdb-multiarch 10.2 from a PPA). > > > >> > > > >> Does this ring any bells for anyone? I'm going to try and get hold of > > > >> a powerpc target to test with to see if I can reproduce it for myself. > > > >> > > > >> Thanks, > > > >> Chris > > > >> > > > > > > > > Did some digging of my own I can report that indeed things aren't working > > > > well for powerpc. I tried updating gdbserver to 12.1 and 13.1. 12.1 was > > > > much the same as 11.2. 13.1 reported that it was unable to send sigkill > > > > when processing the interrupt command. 13.1 also seems not to be able to > > > > respond to the 'info os processes' command from the gdb client > > > > > > > >> > > > > > > What sort of behavior/output do you see? > > > > > > > > > I'll capture some proper output when I'm back in the office but basically once I 'continue' I can't get the gdb prompt back with Ctrl+C. > > > > > > > Is it a tight loop by any change? Or is gdb trapped in a long sequence of instruction-steps? > > > > > > It's a daemon using a g_main_loop() not sure if that counts as a tight loop. GDB shouldn't be doing any stepping. I'll also give a process that runs and finishes when I get a chance to see if there are issues with that. > > > > Got it. It would be useful to see some of the output with "set debug remote 1" and "set debug remote-packet-max-chars -1". It may indicate what's going on. So things get a bit stranger. I tried to replicate my problem using a busybox applet (cat /dev/zero) but I was able to Ctrl-C and continue multiple times. Here's a snippet of debug doing that (gdb) cont Continuing. [remote] Sending packet: $Z0,100040e0,4#d0 [remote] Packet received: OK [remote] Sending packet: $Z0,10036bb8,4#0c [remote] Packet received: OK [remote] Sending packet: $Z0,1003ae68,4#0e [remote] Packet received: OK [remote] Sending packet: $Z0,778e5770,4#f4 [remote] Packet received: OK [remote] Sending packet: $vCont;c:p63a8.-1#e0 [remote] wait: enter [remote] wait: exit ^C[remote] pass_ctrlc: enter [remote] interrupt: enter [remote] interrupt: exit [remote] pass_ctrlc: exit [remote] wait: enter [remote] Packet received: T0201:7fa61a50;40:0fde67f0;thread:p63a8.63a8;core:2; [remote] wait: exit [remote] Sending packet: $qXfer:threads:read::0,1000#92 [remote] Packet received: l<threads>\n<thread id="p63a8.63a8" core="2" name="cat" handle="7792e040"/>\n</threads>\n Program received signal SIGINT, Interrupt. [remote] Sending packet: $z0,100040e0,4#f0 [remote] Packet received: OK [remote] Sending packet: $z0,10036bb8,4#2c [remote] Packet received: OK [remote] Sending packet: $z0,1003ae68,4#2e [remote] Packet received: OK [remote] Sending packet: $z0,778e5770,4#14 [remote] Packet received: OK [remote] Sending packet: $mfde67f0,4#ff [remote] Packet received: 7c000026 [remote] Sending packet: $mfde67ec,4#31 [remote] Packet received: 44000002 [remote] Sending packet: $mfde67f0,4#ff [remote] Packet received: 7c000026 [remote] Sending packet: $mfde67ec,4#31 [remote] Packet received: 44000002 0x0fde67f0 in __GI___libc_write ([remote] Sending packet: $m7fa61a40,40#27 [remote] Packet received: 000000017fa61ab800001000000010007fa61a700002d002fffff00000000000100078287fa61ab87fa61ab8000000017fa61a90100078287792e5c800000000 [remote] Sending packet: $g#67 [remote] Packet received: 000000047fa61a50779355c00000001e7fa61ab800001000000010000fde66c00002d002fffff000000000007fa61a9024002444100a8668000000000000000000000000000000000000000000000000000000000000000077931b78100040e0000000000000000100000003100a000000000000000010000fef37e4000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000fff80000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020080000000000000000000000000000000000000000000000000000000000000080000000000fde67f00002d902240424420fef37e40fde615000000000000000000000000100000c00 [remote] Sending packet: $m10007828,4#67 [remote] Packet received: 2c030000 [remote] Sending packet: $m10007824,4#63 [remote] Packet received: 480556bd [remote] Sending packet: $m10007828,4#67 [remote] Packet received: 2c030000 [remote] Sending packet: $m10007824,4#63 [remote] Packet received: 480556bd [remote] Sending packet: $m7fa61a80,40#2b [remote] Packet received: 000000017fa61ab800000000000010007fa61ab010006b2c0000000000000000000110000000000000001000010000007fa62ae01000683c0000000000000000 fd=0x1e, fd@entry=0x1, buf=buf@entry=0x7fa61ab8, nbytes=nbytes@entry=0x1000) at ../sysdeps/unix/sysv/linux/write.c:26 26 in ../sysdeps/unix/sysv/linux/write.c Now attempting the same thing on a running daemon (gdb) attach 1285 Attaching to program: <redacted>/usr/sbin/modbusd, process 1285 [remote] Sending packet: $vAttach;505#a0 [remote] Packet received: T0001:7fc44e50;40:0f69ec74;thread:p505.505;core:2; [remote] packet_ok: Packet vAttach (attach) is supported [remote] Sending packet: $qXfer:exec-file:read:505:0,1000#b3 [remote] Packet received: l/usr/sbin/modbusd [remote] Sending packet: $qC#b4 [remote] Packet received: QCp505.505 [remote] Sending packet: $Hgp505.505#81 [remote] Packet received: OK ... lots of output skipped [remote] Packet received: l<threads>\n<thread id="p505.505" core="2" name="modbusd" handle="77a7a520"/>\n<thread id="p505.511" core="1" name="gmain" handle="77a3b3a0"/>\n<thread id="p505.512" core="1" name="modbusd" handle="7723a3a0"/>\n<thread id="p505.514" core="1" name="rpc.8" handle="76a393a0"/>\n<thread id="p505.515" core="1" name="cmat:global" handle="75eff3a0"/>\n<thread id="p505.516" core="1" name="cmsr:events" handle="756fe3a0"/>\n<thread id="p505.517" core="1" name="cmbc:modbusd-dy" handle="74efd3a0"/>\n<thread id="p505.58c" core="1" name="rpc.9" handle="742ff3a0"/>\n</threads>\n [New Thread 1285.1297] [New Thread 1285.1298] [New Thread 1285.1300] [New Thread 1285.1301] [New Thread 1285.1302] [New Thread 1285.1303] [New Thread 1285.1420] Thread 1 "modbusd" stopped. [remote] Sending packet: $mf69ec74,4#d5 [remote] Packet received: 7c000026 [remote] Sending packet: $mf69ec70,4#d1 [remote] Packet received: 44000002 [remote] Sending packet: $mf69ec74,4#d5 [remote] Packet received: 7c000026 [remote] Sending packet: $mf69ec70,4#d1 [remote] Packet received: 44000002 0x0f69ec74 in __GI___poll ([remote] Sending packet: $m7fc44e40,40#2e [remote] Packet received: 7fc44e700000000077a8cb78100035707fc44e700000000800000001ffffffff10031fb0000000080f92609c100358207fc44eb00f834ca8ffffffff7fffffff [remote] Sending packet: $g#67 [remote] Packet received: 000000a77fc44e5077a81aa00000020400000008ffffffff000000380000001800000001000000031003e56c7fc44e204400248410038270000000000000000000000000000000000000000000000000000000000000000077a8cb78100035707fc44e780f841e90000000010000000010031fb0000000080f7a37e4fffffffffff8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003ff553f700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000fff80000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000001000000010f69ec740002d902940024840f69ec5c0f87c49c200000008202400010031fb000000c00 [remote] Sending packet: $mf834ca8,4#ce [remote] Packet received: 7c7b1b78 [remote] Sending packet: $mf834ca4,4#ca [remote] Packet received: 4e800421 [remote] Sending packet: $mf834ca8,4#ce [remote] Packet received: 7c7b1b78 [remote] Sending packet: $mf834ca4,4#ca [remote] Packet received: 4e800421 [remote] Sending packet: $m7fc44e80,40#32 [remote] Packet received: 7fc44e90000000010f92609c1003582077a8ba88000000007fc451fc7fc45214100358d8100358d40f92609c100358d07fc44ed00f835274880024847fc45214 fds=0x10031fb0, nfds=0x8, timeout=0xffffffff) at ../sysdeps/unix/sysv/linux/poll.c:29 29 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory. (gdb) cont Continuing. [remote] Sending packet: $Z0,77a40770,4#e7 [remote] Packet received: OK [remote] Sending packet: $vCont;c:p505.-1#78 [remote] wait: enter [remote] wait: exit ^C[remote] pass_ctrlc: enter [remote] interrupt: enter [remote] interrupt: exit [remote] pass_ctrlc: exit I think one of the key differences is the fact that the 2nd process I connected to has multiple threads. I'm not sure if I've got another (on-busybox) daemon that doesn't use threads. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problems interrupting remote target on powerpc 2023-05-01 5:30 ` Chris Packham @ 2023-05-01 21:20 ` Chris Packham 2023-05-02 12:46 ` Tom Tromey 2023-05-02 12:55 ` Luis Machado 1 sibling, 1 reply; 12+ messages in thread From: Chris Packham @ 2023-05-01 21:20 UTC (permalink / raw) To: Luis Machado; +Cc: GDB Mailing list On Mon, May 1, 2023 at 5:30 PM Chris Packham <judge.packham@gmail.com> wrote: > > On Sat, Apr 29, 2023 at 1:02 AM Luis Machado <luis.machado@arm.com> wrote: > > > > On 4/28/23 12:25, Chris Packham wrote: > > > > > > > > > On Fri, 28 Apr 2023, 9:41 PM Luis Machado, <luis.machado@arm.com <mailto:luis.machado@arm.com>> wrote: > > > > > > On 4/28/23 10:38, Chris Packham wrote: > > > > > > > > > > > > On Fri, 28 Apr 2023, 9:19 PM Luis Machado, <luis.machado@arm.com <mailto:luis.machado@arm.com> <mailto:luis.machado@arm.com <mailto:luis.machado@arm.com>>> wrote: > > > > > > > > On 4/28/23 10:14, Chris Packham via Gdb wrote: > > > > > On Thu, 27 Apr 2023, 4:55 PM Chris Packham, <judge.packham@gmail.com <mailto:judge.packham@gmail.com> <mailto:judge.packham@gmail.com <mailto:judge.packham@gmail.com>>> wrote: > > > > > > > > > >> Hi GDB, > > > > >> > > > > >> I've had a few users report to me issues with interrupting a running > > > > >> process after continuing when attached to a remote gdbserver running > > > > >> on a powerpc target. Everything seems to work properly on arm and > > > > >> aarch64 so there might be some powerpc or big-endian specific issue > > > > >> lurking. > > > > >> > > > > >> The gdbserver version we're currently using is from gdb-11.2 built > > > > >> from source and most users have gdb-multiarch 12.1 from ubuntu 22.04 > > > > >> (some might still be using gdb-multiarch 10.2 from a PPA). > > > > >> > > > > >> Does this ring any bells for anyone? I'm going to try and get hold of > > > > >> a powerpc target to test with to see if I can reproduce it for myself. > > > > >> > > > > >> Thanks, > > > > >> Chris > > > > >> > > > > > > > > > > Did some digging of my own I can report that indeed things aren't working > > > > > well for powerpc. I tried updating gdbserver to 12.1 and 13.1. 12.1 was > > > > > much the same as 11.2. 13.1 reported that it was unable to send sigkill > > > > > when processing the interrupt command. 13.1 also seems not to be able to > > > > > respond to the 'info os processes' command from the gdb client > > > > > > > > > >> > > > > > > > > What sort of behavior/output do you see? > > > > > > > > > > > > I'll capture some proper output when I'm back in the office but basically once I 'continue' I can't get the gdb prompt back with Ctrl+C. > > > > > > > > > > Is it a tight loop by any change? Or is gdb trapped in a long sequence of instruction-steps? > > > > > > > > > It's a daemon using a g_main_loop() not sure if that counts as a tight loop. GDB shouldn't be doing any stepping. I'll also give a process that runs and finishes when I get a chance to see if there are issues with that. > > > > > > > Got it. It would be useful to see some of the output with "set debug remote 1" and "set debug remote-packet-max-chars -1". It may indicate what's going on. > > So things get a bit stranger. I tried to replicate my problem using a > busybox applet (cat /dev/zero) but I was able to Ctrl-C and continue > multiple times. Here's a snippet of debug doing that > > (gdb) cont > Continuing. > [remote] Sending packet: $Z0,100040e0,4#d0 > [remote] Packet received: OK > [remote] Sending packet: $Z0,10036bb8,4#0c > [remote] Packet received: OK > [remote] Sending packet: $Z0,1003ae68,4#0e > [remote] Packet received: OK > [remote] Sending packet: $Z0,778e5770,4#f4 > [remote] Packet received: OK > [remote] Sending packet: $vCont;c:p63a8.-1#e0 > [remote] wait: enter > [remote] wait: exit > ^C[remote] pass_ctrlc: enter > [remote] interrupt: enter > [remote] interrupt: exit > [remote] pass_ctrlc: exit > [remote] wait: enter > [remote] Packet received: T0201:7fa61a50;40:0fde67f0;thread:p63a8.63a8;core:2; > [remote] wait: exit > [remote] Sending packet: $qXfer:threads:read::0,1000#92 > [remote] Packet received: l<threads>\n<thread id="p63a8.63a8" core="2" > name="cat" handle="7792e040"/>\n</threads>\n > > Program received signal SIGINT, Interrupt. > [remote] Sending packet: $z0,100040e0,4#f0 > [remote] Packet received: OK > [remote] Sending packet: $z0,10036bb8,4#2c > [remote] Packet received: OK > [remote] Sending packet: $z0,1003ae68,4#2e > [remote] Packet received: OK > [remote] Sending packet: $z0,778e5770,4#14 > [remote] Packet received: OK > [remote] Sending packet: $mfde67f0,4#ff > [remote] Packet received: 7c000026 > [remote] Sending packet: $mfde67ec,4#31 > [remote] Packet received: 44000002 > [remote] Sending packet: $mfde67f0,4#ff > [remote] Packet received: 7c000026 > [remote] Sending packet: $mfde67ec,4#31 > [remote] Packet received: 44000002 > 0x0fde67f0 in __GI___libc_write ([remote] Sending packet: $m7fa61a40,40#27 > [remote] Packet received: > 000000017fa61ab800001000000010007fa61a700002d002fffff00000000000100078287fa61ab87fa61ab8000000017fa61a90100078287792e5c800000000 > [remote] Sending packet: $g#67 > [remote] Packet received: > 000000047fa61a50779355c00000001e7fa61ab800001000000010000fde66c00002d002fffff000000000007fa61a9024002444100a8668000000000000000000000000000000000000000000000000000000000000000077931b78100040e0000000000000000100000003100a000000000000000010000fef37e4000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000fff80000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020080000000000000000000000000000000000000000000000000000000000000080000000000fde67f00002d902240424420fef37e40fde615000000000000000000000000100000c00 > [remote] Sending packet: $m10007828,4#67 > [remote] Packet received: 2c030000 > [remote] Sending packet: $m10007824,4#63 > [remote] Packet received: 480556bd > [remote] Sending packet: $m10007828,4#67 > [remote] Packet received: 2c030000 > [remote] Sending packet: $m10007824,4#63 > [remote] Packet received: 480556bd > [remote] Sending packet: $m7fa61a80,40#2b > [remote] Packet received: > 000000017fa61ab800000000000010007fa61ab010006b2c0000000000000000000110000000000000001000010000007fa62ae01000683c0000000000000000 > fd=0x1e, fd@entry=0x1, buf=buf@entry=0x7fa61ab8, > nbytes=nbytes@entry=0x1000) at ../sysdeps/unix/sysv/linux/write.c:26 > 26 in ../sysdeps/unix/sysv/linux/write.c > > Now attempting the same thing on a running daemon > > (gdb) attach 1285 > Attaching to program: <redacted>/usr/sbin/modbusd, process 1285 > [remote] Sending packet: $vAttach;505#a0 > [remote] Packet received: T0001:7fc44e50;40:0f69ec74;thread:p505.505;core:2; > [remote] packet_ok: Packet vAttach (attach) is supported > [remote] Sending packet: $qXfer:exec-file:read:505:0,1000#b3 > [remote] Packet received: l/usr/sbin/modbusd > [remote] Sending packet: $qC#b4 > [remote] Packet received: QCp505.505 > [remote] Sending packet: $Hgp505.505#81 > [remote] Packet received: OK > ... lots of output skipped > [remote] Packet received: l<threads>\n<thread id="p505.505" core="2" > name="modbusd" handle="77a7a520"/>\n<thread id="p505.511" core="1" > name="gmain" handle="77a3b3a0"/>\n<thread id="p505.512" core="1" > name="modbusd" handle="7723a3a0"/>\n<thread id="p505.514" core="1" > name="rpc.8" handle="76a393a0"/>\n<thread id="p505.515" core="1" > name="cmat:global" handle="75eff3a0"/>\n<thread id="p505.516" core="1" > name="cmsr:events" handle="756fe3a0"/>\n<thread id="p505.517" core="1" > name="cmbc:modbusd-dy" handle="74efd3a0"/>\n<thread id="p505.58c" > core="1" name="rpc.9" handle="742ff3a0"/>\n</threads>\n > [New Thread 1285.1297] > [New Thread 1285.1298] > [New Thread 1285.1300] > [New Thread 1285.1301] > [New Thread 1285.1302] > [New Thread 1285.1303] > [New Thread 1285.1420] > > Thread 1 "modbusd" stopped. > [remote] Sending packet: $mf69ec74,4#d5 > [remote] Packet received: 7c000026 > [remote] Sending packet: $mf69ec70,4#d1 > [remote] Packet received: 44000002 > [remote] Sending packet: $mf69ec74,4#d5 > [remote] Packet received: 7c000026 > [remote] Sending packet: $mf69ec70,4#d1 > [remote] Packet received: 44000002 > 0x0f69ec74 in __GI___poll ([remote] Sending packet: $m7fc44e40,40#2e > [remote] Packet received: > 7fc44e700000000077a8cb78100035707fc44e700000000800000001ffffffff10031fb0000000080f92609c100358207fc44eb00f834ca8ffffffff7fffffff > [remote] Sending packet: $g#67 > [remote] Packet received: > 000000a77fc44e5077a81aa00000020400000008ffffffff000000380000001800000001000000031003e56c7fc44e204400248410038270000000000000000000000000000000000000000000000000000000000000000077a8cb78100035707fc44e780f841e90000000010000000010031fb0000000080f7a37e4fffffffffff8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003ff553f700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000fff80000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000001000000010f69ec740002d902940024840f69ec5c0f87c49c200000008202400010031fb000000c00 > [remote] Sending packet: $mf834ca8,4#ce > [remote] Packet received: 7c7b1b78 > [remote] Sending packet: $mf834ca4,4#ca > [remote] Packet received: 4e800421 > [remote] Sending packet: $mf834ca8,4#ce > [remote] Packet received: 7c7b1b78 > [remote] Sending packet: $mf834ca4,4#ca > [remote] Packet received: 4e800421 > [remote] Sending packet: $m7fc44e80,40#32 > [remote] Packet received: > 7fc44e90000000010f92609c1003582077a8ba88000000007fc451fc7fc45214100358d8100358d40f92609c100358d07fc44ed00f835274880024847fc45214 > fds=0x10031fb0, nfds=0x8, timeout=0xffffffff) at > ../sysdeps/unix/sysv/linux/poll.c:29 > 29 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory. > (gdb) cont > Continuing. > [remote] Sending packet: $Z0,77a40770,4#e7 > [remote] Packet received: OK > [remote] Sending packet: $vCont;c:p505.-1#78 > [remote] wait: enter > [remote] wait: exit > ^C[remote] pass_ctrlc: enter > [remote] interrupt: enter > [remote] interrupt: exit > [remote] pass_ctrlc: exit > > I think one of the key differences is the fact that the 2nd process I > connected to has multiple threads. I'm not sure if I've got another > (on-busybox) daemon that doesn't use threads. Found a non-threaded daemon (still has forks) and that doesn't respond to Ctrl-C either. I am however able to get gdb back by sending it a kill -2 on the remote devices console. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problems interrupting remote target on powerpc 2023-05-01 21:20 ` Chris Packham @ 2023-05-02 12:46 ` Tom Tromey 0 siblings, 0 replies; 12+ messages in thread From: Tom Tromey @ 2023-05-02 12:46 UTC (permalink / raw) To: Chris Packham via Gdb; +Cc: Luis Machado, Chris Packham >>>>> "Chris" == Chris Packham via Gdb <gdb@sourceware.org> writes: Chris> Found a non-threaded daemon (still has forks) and that doesn't respond Chris> to Ctrl-C either. I am however able to get gdb back by sending it a Chris> kill -2 on the remote devices console. I wonder if this is the sigwait problem, see: https://sourceware.org/bugzilla/show_bug.cgi?id=9425 https://sourceware.org/bugzilla/show_bug.cgi?id=14559 And also one proposed way to fix it: https://sourceware.org/bugzilla/show_bug.cgi?id=15250 Tom ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problems interrupting remote target on powerpc 2023-05-01 5:30 ` Chris Packham 2023-05-01 21:20 ` Chris Packham @ 2023-05-02 12:55 ` Luis Machado 1 sibling, 0 replies; 12+ messages in thread From: Luis Machado @ 2023-05-02 12:55 UTC (permalink / raw) To: Chris Packham; +Cc: GDB Mailing list On 5/1/23 06:30, Chris Packham wrote: > On Sat, Apr 29, 2023 at 1:02 AM Luis Machado <luis.machado@arm.com> wrote: >> >> On 4/28/23 12:25, Chris Packham wrote: >>> >>> >>> On Fri, 28 Apr 2023, 9:41 PM Luis Machado, <luis.machado@arm.com <mailto:luis.machado@arm.com>> wrote: >>> >>> On 4/28/23 10:38, Chris Packham wrote: >>> > >>> > >>> > On Fri, 28 Apr 2023, 9:19 PM Luis Machado, <luis.machado@arm.com <mailto:luis.machado@arm.com> <mailto:luis.machado@arm.com <mailto:luis.machado@arm.com>>> wrote: >>> > >>> > On 4/28/23 10:14, Chris Packham via Gdb wrote: >>> > > On Thu, 27 Apr 2023, 4:55 PM Chris Packham, <judge.packham@gmail.com <mailto:judge.packham@gmail.com> <mailto:judge.packham@gmail.com <mailto:judge.packham@gmail.com>>> wrote: >>> > > >>> > >> Hi GDB, >>> > >> >>> > >> I've had a few users report to me issues with interrupting a running >>> > >> process after continuing when attached to a remote gdbserver running >>> > >> on a powerpc target. Everything seems to work properly on arm and >>> > >> aarch64 so there might be some powerpc or big-endian specific issue >>> > >> lurking. >>> > >> >>> > >> The gdbserver version we're currently using is from gdb-11.2 built >>> > >> from source and most users have gdb-multiarch 12.1 from ubuntu 22.04 >>> > >> (some might still be using gdb-multiarch 10.2 from a PPA). >>> > >> >>> > >> Does this ring any bells for anyone? I'm going to try and get hold of >>> > >> a powerpc target to test with to see if I can reproduce it for myself. >>> > >> >>> > >> Thanks, >>> > >> Chris >>> > >> >>> > > >>> > > Did some digging of my own I can report that indeed things aren't working >>> > > well for powerpc. I tried updating gdbserver to 12.1 and 13.1. 12.1 was >>> > > much the same as 11.2. 13.1 reported that it was unable to send sigkill >>> > > when processing the interrupt command. 13.1 also seems not to be able to >>> > > respond to the 'info os processes' command from the gdb client >>> > > >>> > >> >>> > >>> > What sort of behavior/output do you see? >>> > >>> > >>> > I'll capture some proper output when I'm back in the office but basically once I 'continue' I can't get the gdb prompt back with Ctrl+C. >>> > >>> >>> Is it a tight loop by any change? Or is gdb trapped in a long sequence of instruction-steps? >>> >>> >>> It's a daemon using a g_main_loop() not sure if that counts as a tight loop. GDB shouldn't be doing any stepping. I'll also give a process that runs and finishes when I get a chance to see if there are issues with that. >>> >> >> Got it. It would be useful to see some of the output with "set debug remote 1" and "set debug remote-packet-max-chars -1". It may indicate what's going on. > > So things get a bit stranger. I tried to replicate my problem using a > busybox applet (cat /dev/zero) but I was able to Ctrl-C and continue > multiple times. Here's a snippet of debug doing that > > (gdb) cont > Continuing. > [remote] Sending packet: $Z0,100040e0,4#d0 > [remote] Packet received: OK > [remote] Sending packet: $Z0,10036bb8,4#0c > [remote] Packet received: OK > [remote] Sending packet: $Z0,1003ae68,4#0e > [remote] Packet received: OK > [remote] Sending packet: $Z0,778e5770,4#f4 > [remote] Packet received: OK > [remote] Sending packet: $vCont;c:p63a8.-1#e0 > [remote] wait: enter > [remote] wait: exit > ^C[remote] pass_ctrlc: enter > [remote] interrupt: enter > [remote] interrupt: exit > [remote] pass_ctrlc: exit > [remote] wait: enter > [remote] Packet received: T0201:7fa61a50;40:0fde67f0;thread:p63a8.63a8;core:2; > [remote] wait: exit > [remote] Sending packet: $qXfer:threads:read::0,1000#92 > [remote] Packet received: l<threads>\n<thread id="p63a8.63a8" core="2" > name="cat" handle="7792e040"/>\n</threads>\n > > Program received signal SIGINT, Interrupt. > [remote] Sending packet: $z0,100040e0,4#f0 > [remote] Packet received: OK > [remote] Sending packet: $z0,10036bb8,4#2c > [remote] Packet received: OK > [remote] Sending packet: $z0,1003ae68,4#2e > [remote] Packet received: OK > [remote] Sending packet: $z0,778e5770,4#14 > [remote] Packet received: OK > [remote] Sending packet: $mfde67f0,4#ff > [remote] Packet received: 7c000026 > [remote] Sending packet: $mfde67ec,4#31 > [remote] Packet received: 44000002 > [remote] Sending packet: $mfde67f0,4#ff > [remote] Packet received: 7c000026 > [remote] Sending packet: $mfde67ec,4#31 > [remote] Packet received: 44000002 > 0x0fde67f0 in __GI___libc_write ([remote] Sending packet: $m7fa61a40,40#27 > [remote] Packet received: > 000000017fa61ab800001000000010007fa61a700002d002fffff00000000000100078287fa61ab87fa61ab8000000017fa61a90100078287792e5c800000000 > [remote] Sending packet: $g#67 > [remote] Packet received: > 000000047fa61a50779355c00000001e7fa61ab800001000000010000fde66c00002d002fffff000000000007fa61a9024002444100a8668000000000000000000000000000000000000000000000000000000000000000077931b78100040e0000000000000000100000003100a000000000000000010000fef37e4000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000fff80000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020080000000000000000000000000000000000000000000000000000000000000080000000000fde67f00002d902240424420fef37e40fde615000000000000000000000000100000c00 > [remote] Sending packet: $m10007828,4#67 > [remote] Packet received: 2c030000 > [remote] Sending packet: $m10007824,4#63 > [remote] Packet received: 480556bd > [remote] Sending packet: $m10007828,4#67 > [remote] Packet received: 2c030000 > [remote] Sending packet: $m10007824,4#63 > [remote] Packet received: 480556bd > [remote] Sending packet: $m7fa61a80,40#2b > [remote] Packet received: > 000000017fa61ab800000000000010007fa61ab010006b2c0000000000000000000110000000000000001000010000007fa62ae01000683c0000000000000000 > fd=0x1e, fd@entry=0x1, buf=buf@entry=0x7fa61ab8, > nbytes=nbytes@entry=0x1000) at ../sysdeps/unix/sysv/linux/write.c:26 > 26 in ../sysdeps/unix/sysv/linux/write.c > > Now attempting the same thing on a running daemon > > (gdb) attach 1285 > Attaching to program: <redacted>/usr/sbin/modbusd, process 1285 > [remote] Sending packet: $vAttach;505#a0 > [remote] Packet received: T0001:7fc44e50;40:0f69ec74;thread:p505.505;core:2; > [remote] packet_ok: Packet vAttach (attach) is supported > [remote] Sending packet: $qXfer:exec-file:read:505:0,1000#b3 > [remote] Packet received: l/usr/sbin/modbusd > [remote] Sending packet: $qC#b4 > [remote] Packet received: QCp505.505 > [remote] Sending packet: $Hgp505.505#81 > [remote] Packet received: OK > ... lots of output skipped > [remote] Packet received: l<threads>\n<thread id="p505.505" core="2" > name="modbusd" handle="77a7a520"/>\n<thread id="p505.511" core="1" > name="gmain" handle="77a3b3a0"/>\n<thread id="p505.512" core="1" > name="modbusd" handle="7723a3a0"/>\n<thread id="p505.514" core="1" > name="rpc.8" handle="76a393a0"/>\n<thread id="p505.515" core="1" > name="cmat:global" handle="75eff3a0"/>\n<thread id="p505.516" core="1" > name="cmsr:events" handle="756fe3a0"/>\n<thread id="p505.517" core="1" > name="cmbc:modbusd-dy" handle="74efd3a0"/>\n<thread id="p505.58c" > core="1" name="rpc.9" handle="742ff3a0"/>\n</threads>\n > [New Thread 1285.1297] > [New Thread 1285.1298] > [New Thread 1285.1300] > [New Thread 1285.1301] > [New Thread 1285.1302] > [New Thread 1285.1303] > [New Thread 1285.1420] > > Thread 1 "modbusd" stopped. > [remote] Sending packet: $mf69ec74,4#d5 > [remote] Packet received: 7c000026 > [remote] Sending packet: $mf69ec70,4#d1 > [remote] Packet received: 44000002 > [remote] Sending packet: $mf69ec74,4#d5 > [remote] Packet received: 7c000026 > [remote] Sending packet: $mf69ec70,4#d1 > [remote] Packet received: 44000002 > 0x0f69ec74 in __GI___poll ([remote] Sending packet: $m7fc44e40,40#2e > [remote] Packet received: > 7fc44e700000000077a8cb78100035707fc44e700000000800000001ffffffff10031fb0000000080f92609c100358207fc44eb00f834ca8ffffffff7fffffff > [remote] Sending packet: $g#67 > [remote] Packet received: > 000000a77fc44e5077a81aa00000020400000008ffffffff000000380000001800000001000000031003e56c7fc44e204400248410038270000000000000000000000000000000000000000000000000000000000000000077a8cb78100035707fc44e780f841e90000000010000000010031fb0000000080f7a37e4fffffffffff8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003ff553f700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000fff80000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000001000000010f69ec740002d902940024840f69ec5c0f87c49c200000008202400010031fb000000c00 > [remote] Sending packet: $mf834ca8,4#ce > [remote] Packet received: 7c7b1b78 > [remote] Sending packet: $mf834ca4,4#ca > [remote] Packet received: 4e800421 > [remote] Sending packet: $mf834ca8,4#ce > [remote] Packet received: 7c7b1b78 > [remote] Sending packet: $mf834ca4,4#ca > [remote] Packet received: 4e800421 > [remote] Sending packet: $m7fc44e80,40#32 > [remote] Packet received: > 7fc44e90000000010f92609c1003582077a8ba88000000007fc451fc7fc45214100358d8100358d40f92609c100358d07fc44ed00f835274880024847fc45214 > fds=0x10031fb0, nfds=0x8, timeout=0xffffffff) at > ../sysdeps/unix/sysv/linux/poll.c:29 > 29 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory. > (gdb) cont > Continuing. > [remote] Sending packet: $Z0,77a40770,4#e7 > [remote] Packet received: OK > [remote] Sending packet: $vCont;c:p505.-1#78 > [remote] wait: enter > [remote] wait: exit > ^C[remote] pass_ctrlc: enter > [remote] interrupt: enter > [remote] interrupt: exit > [remote] pass_ctrlc: exit > > I think one of the key differences is the fact that the 2nd process I > connected to has multiple threads. I'm not sure if I've got another > (on-busybox) daemon that doesn't use threads. That's interesting. I wonder if this reproduces with a top-of-tree gdbserver? GDB seems to be doing the expected here, sending the ctrl+c over. gdbserver might be getting things wrong, or it didn't manage to interrupt the target. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2023-05-02 12:55 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-04-27 4:55 Problems interrupting remote target on powerpc Chris Packham 2023-04-28 9:14 ` Chris Packham 2023-04-28 9:18 ` Luis Machado 2023-04-28 9:38 ` Chris Packham 2023-04-28 9:40 ` Luis Machado 2023-04-28 11:25 ` Chris Packham 2023-04-28 13:02 ` Luis Machado 2023-04-28 14:05 ` Joel Brobecker 2023-05-01 5:30 ` Chris Packham 2023-05-01 21:20 ` Chris Packham 2023-05-02 12:46 ` Tom Tromey 2023-05-02 12:55 ` Luis Machado
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).