* 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).