From: Chris Packham <judge.packham@gmail.com>
To: Luis Machado <luis.machado@arm.com>
Cc: GDB Mailing list <gdb@sourceware.org>
Subject: Re: Problems interrupting remote target on powerpc
Date: Mon, 1 May 2023 17:30:30 +1200 [thread overview]
Message-ID: <CAFOYHZBgJbFNb7NM5Sv461-G7VpL8Lxt_5jRjrs_9HR8VdXCmg@mail.gmail.com> (raw)
In-Reply-To: <d80d8961-cfbf-210f-77fd-ceb342faa5e3@arm.com>
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.
next prev parent reply other threads:[~2023-05-01 5:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-27 4:55 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 [this message]
2023-05-01 21:20 ` Chris Packham
2023-05-02 12:46 ` Tom Tromey
2023-05-02 12:55 ` Luis Machado
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFOYHZBgJbFNb7NM5Sv461-G7VpL8Lxt_5jRjrs_9HR8VdXCmg@mail.gmail.com \
--to=judge.packham@gmail.com \
--cc=gdb@sourceware.org \
--cc=luis.machado@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).