From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id k/J0K0ItUGRmRzwAWB0awg (envelope-from ) for ; Mon, 01 May 2023 17:21:06 -0400 Received: by simark.ca (Postfix, from userid 112) id 9FABA1E11B; Mon, 1 May 2023 17:21:06 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=Qo/l4nFL; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 932B91E0D3 for ; Mon, 1 May 2023 17:21:02 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0B2793858425 for ; Mon, 1 May 2023 21:21:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0B2793858425 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1682976061; bh=WlopG+ORPqZHy/tP4WZFg9wtMykS6gkP3G1hzDXyjBc=; h=References:In-Reply-To:Date:Subject:To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=Qo/l4nFLd2yo+MtrknDgIQfKFIVBtfdDoHtcf3YIWoH35oeVQViGwjhK19SZA/FHV 6wd2BQKXDcU5TYpMM3D5kOS3ZDc9MND3Z1pvHqTqhc7VNQN7DVvzlbSCyudddoNY7J 0wwAuT9C601bSsu7MkEu5hQYJGPlbOX1N60SS9eo= Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) by sourceware.org (Postfix) with ESMTPS id 8B0363858D1E for ; Mon, 1 May 2023 21:20:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8B0363858D1E Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-50bc075d6b2so3948497a12.0 for ; Mon, 01 May 2023 14:20:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682976030; x=1685568030; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WlopG+ORPqZHy/tP4WZFg9wtMykS6gkP3G1hzDXyjBc=; b=fK4sK2/m4G4mN7HaZr0/ics3TO2qVf6xbwpIBLNoQJ+z5lAFMbKqs4Myusgi8SVupg 9zdwm3to27EX78y7yDEUNrEZT8/zR0qjM/MiUw+5q7CYiL7fpBZJxgAQhy4aMNnQrc1f YrNelfPlgRVkGIwcmquKWjMsdSkONY28pmh9hRTGIFL6ch53MaQAX+dq/9bfBxiTWj6V CtJJVX1+28qrR8KmAsgdjPuX8S53yLjkCAXfINPz0KnDs0Vt2JaFdhXX2G0p2lpz1xxk cNTIJ+fF54jwFVM1S7xsXC2Cw2+VgUCHfMwWPjPj4YKTugIPzzlfNlF3mlQmTqGxF2cD bedQ== X-Gm-Message-State: AC+VfDwHq1ZYcU29X/gy8pyl5iJBfGX6V7CmHkk9mwdCdHIuQS0q+orD Ih6ytusJ+ol5FXZQg62hGeBnWj/YVg8tBNrb0YQ1LBsniZQ= X-Google-Smtp-Source: ACHHUZ6FoT9TYHTqTz+TLadyDGivU2T/TmVQ9q4pFrOh5nhPTgiXVJ+wloV3eI7Ku5o5jcbZiLGForolwKGLLwm5qLE= X-Received: by 2002:a17:907:ea5:b0:94a:7a0f:7851 with SMTP id ho37-20020a1709070ea500b0094a7a0f7851mr14066876ejc.41.1682976029968; Mon, 01 May 2023 14:20:29 -0700 (PDT) MIME-Version: 1.0 References: <00c24cea-f256-3149-dcc7-1bad08e8bef8@arm.com> In-Reply-To: Date: Tue, 2 May 2023 09:20:17 +1200 Message-ID: Subject: Re: Problems interrupting remote target on powerpc To: Luis Machado Cc: GDB Mailing list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Chris Packham via Gdb Reply-To: Chris Packham Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" On Mon, May 1, 2023 at 5:30=E2=80=AFPM Chris Packham wrote: > > On Sat, Apr 29, 2023 at 1:02=E2=80=AFAM Luis Machado wrote: > > > > On 4/28/23 12:25, Chris Packham wrote: > > > > > > > > > On Fri, 28 Apr 2023, 9:41 PM Luis Machado, > wrote: > > > > > > On 4/28/23 10:38, Chris Packham wrote: > > > > > > > > > > > > On Fri, 28 Apr 2023, 9:19 PM Luis Machado, >> wrote: > > > > > > > > On 4/28/23 10:14, Chris Packham via Gdb wrote: > > > > > On Thu, 27 Apr 2023, 4:55 PM Chris Packham, >> wrote: > > > > > > > > > >> Hi GDB, > > > > >> > > > > >> I've had a few users report to me issues with interrup= ting a running > > > > >> process after continuing when attached to a remote gdb= server running > > > > >> on a powerpc target. Everything seems to work properly= on arm and > > > > >> aarch64 so there might be some powerpc or big-endian s= pecific issue > > > > >> lurking. > > > > >> > > > > >> The gdbserver version we're currently using is from gd= b-11.2 built > > > > >> from source and most users have gdb-multiarch 12.1 fro= m ubuntu 22.04 > > > > >> (some might still be using gdb-multiarch 10.2 from a P= PA). > > > > >> > > > > >> 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 reproduc= e it for myself. > > > > >> > > > > >> Thanks, > > > > >> Chris > > > > >> > > > > > > > > > > Did some digging of my own I can report that indeed thi= ngs aren't working > > > > > well for powerpc. I tried updating gdbserver to 12.1 an= d 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 bu= t 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 seq= uence of instruction-steps? > > > > > > > > > It's a daemon using a g_main_loop() not sure if that counts as a tigh= t 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 re= mote 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\n name=3D"cat" handle=3D"7792e040"/>\n\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#2= 7 > [remote] Packet received: > 000000017fa61ab800001000000010007fa61a700002d002fffff00000000000100078287= fa61ab87fa61ab8000000017fa61a90100078287792e5c800000000 > [remote] Sending packet: $g#67 > [remote] Packet received: > 000000047fa61a50779355c00000001e7fa61ab800001000000010000fde66c00002d002f= ffff000000000007fa61a9024002444100a8668000000000000000000000000000000000000= 000000000000000000000000000077931b78100040e0000000000000000100000003100a000= 000000000000010000fef37e400000001000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 0000000000000000000000000000000000000000000000000000000000000000fff80000000= 000000000000000000000000000000000000200000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000020080000000000000000000000000000000000000000000000000000= 000000000080000000000fde67f00002d902240424420fef37e40fde6150000000000000000= 00000000100000c00 > [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: > 000000017fa61ab800000000000010007fa61ab010006b2c0000000000000000000110000= 000000000001000010000007fa62ae01000683c0000000000000000 > fd=3D0x1e, fd@entry=3D0x1, buf=3Dbuf@entry=3D0x7fa61ab8, > nbytes=3Dnbytes@entry=3D0x1000) 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: /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\n name=3D"modbusd" handle=3D"77a7a520"/>\n name=3D"gmain" handle=3D"77a3b3a0"/>\n name=3D"modbusd" handle=3D"7723a3a0"/>\n name=3D"rpc.8" handle=3D"76a393a0"/>\n name=3D"cmat:global" handle=3D"75eff3a0"/>\n name=3D"cmsr:events" handle=3D"756fe3a0"/>\n name=3D"cmbc:modbusd-dy" handle=3D"74efd3a0"/>\n core=3D"1" name=3D"rpc.9" handle=3D"742ff3a0"/>\n\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: > 7fc44e700000000077a8cb78100035707fc44e700000000800000001ffffffff10031fb00= 00000080f92609c100358207fc44eb00f834ca8ffffffff7fffffff > [remote] Sending packet: $g#67 > [remote] Packet received: > 000000a77fc44e5077a81aa00000020400000008ffffffff0000003800000018000000010= 00000031003e56c7fc44e204400248410038270000000000000000000000000000000000000= 000000000000000000000000000077a8cb78100035707fc44e780f841e90000000010000000= 010031fb0000000080f7a37e4fffffffffff800000000000000000000000000000000000000= 0000000000000000000000000000000000000000000000000000003ff553f70000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 0000000000000000000000000000000000000000000000000000000000000000fff80000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000020000000000000000000000000000000000000000000000000000000= 000000000001000000010f69ec740002d902940024840f69ec5c0f87c49c200000008202400= 010031fb000000c00 > [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: > 7fc44e90000000010f92609c1003582077a8ba88000000007fc451fc7fc45214100358d81= 00358d40f92609c100358d07fc44ed00f835274880024847fc45214 > fds=3D0x10031fb0, nfds=3D0x8, timeout=3D0xffffffff) 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.