From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 915C1384AB69; Fri, 26 Apr 2024 20:24:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 915C1384AB69 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1714163052; bh=CTX0nB7UW5XWztTPU36NX4yjwznOPOp4K62nb/Pq3DI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GxC/Wi5fKynZtaW9cNOFceetNG6ot7T8lQ1LbsC9etBvXqXDe7Dg1aDUK7td56+SE jbWQHiLd/5fTZgJpHnXQSL+lQuckD5YCaDHcEkZ+SbqeM1L0tHBO7cUAVqv7M/Ri40 UN1mx2OuzSfRFxv8cJU3qSR0hRJjEdTBN2dNgDM8= From: "cvs-commit at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug server/31554] gdbserver --once --multi mishandles run & attach failures Date: Fri, 26 Apr 2024 20:24:12 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: server X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: pedro at palves dot net X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31554 --- Comment #3 from Sourceware Commits --- The master branch has been updated by Pedro Alves : https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3Df1fc8dc2dccb= 4a224cdd1c3973c7a09a752aa95b commit f1fc8dc2dccb4a224cdd1c3973c7a09a752aa95b Author: Pedro Alves Date: Wed Apr 17 19:26:32 2024 +0100 Fix "attach" failure handling with GDBserver This fixes the same issue as the previous patch, but for "attach" instead of "run". If attaching to a process with "attach" (vAttach packet) fails, GDBserver throws an error that escapes all the way to the top level. When an error escapes all the way like that, GDBserver interprets it as a disconnection, and either goes back to waiting for a new GDB connection, or exits, if --once was specified. Here's an example: On the GDB side: ... (gdb) tar extended-remote :9999 ... Remote debugging using :9999 (gdb) attach 1 Attaching to process 1 Attaching to process 1 failed (gdb) On the GDBserver side: $ gdbserver --once --multi :9999 Listening on port 9999 Remote debugging from host 127.0.0.1, port 37464 gdbserver: Cannot attach to process 1: Operation not permitted (1) $ # gdbserver exited This is wrong, as we've connected with extended-remote/--multi. GDBserver should just report an error to vAttach, and continue connected to GDB, waiting for other commands. This commit fixes GDBserver by catching the error locally in handle_v_attach. Note we now let pid =3D=3D 0 pass down to attach_inferior. That is so = we get a useful textual error message to report to GDB. This fixes a couple KFAILs in gdb.base/attach.exp. Still, I thought it would be useful to add a new testcase specifically for this scenario, in case gdb.base/attach.exp is ever split and stops trying to attach again after a failed attach, with the same GDB session. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D19558 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31554 Change-Id: I25314c7e5f1435eff69cb84d57ecac13d8de3393 Approved-By: Tom Tromey --=20 You are receiving this mail because: You are on the CC list for the bug.=