Re: Problems interrupting remote target on powerpc

Luis Machado via Gdb <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <[email protected]> 
On 5/1/23 06:30, Chris Packham wrote:
> On Sat, Apr 29, 2023 at 1:02 AM Luis Machado <[email protected]> wrote:
>>
>> On 4/28/23 12:25, Chris Packham wrote:
>>>
>>>
>>> On Fri, 28 Apr 2023, 9:41 PM Luis Machado, <[email protected] <mailto:[email protected]>> wrote:
>>>
>>>      On 4/28/23 10:38, Chris Packham wrote:
>>>       >
>>>       >
>>>       > On Fri, 28 Apr 2023, 9:19 PM Luis Machado, <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote:
>>>       >
>>>       >     On 4/28/23 10:14, Chris Packham via Gdb wrote:
>>>       >      > On Thu, 27 Apr 2023, 4:55 PM Chris Packham, <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> 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:
> 000000047fa61a50779355c00000001e7fa61ab800001000000010000fde66c00002d002fffff000000000007fa61a9024002444100a8668000000000000000000000000000000000000000000000000000000000000000077931b78100040e0000000000000000100000003100a000000000000000010000fef37e4000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000fff80000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020080000000000000000000000000000000000000000000000000000000000000080000000000fde67f00002d902240424420fef37
 e40fde615000000000000000000000000100000c00
> [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:
> 000000a77fc44e5077a81aa00000020400000008ffffffff000000380000001800000001000000031003e56c7fc44e204400248410038270000000000000000000000000000000000000000000000000000000000000000077a8cb78100035707fc44e780f841e90000000010000000010031fb0000000080f7a37e4fffffffffff8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003ff553f700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000fff80000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000001000000010f69ec740002d902940024840f69ec
 5c0f87c49c200000008202400010031fb000000c00
> [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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.