From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by sourceware.org (Postfix) with ESMTPS id A9A453858D32 for ; Sat, 27 Apr 2024 08:24:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A9A453858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A9A453858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::530 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714206278; cv=none; b=QglH9tjIB/3VF1Z3J0/IfUiQhq5I1RqM69pk8+MxGDvg6L+gXwDxvfwQlXDgolcx2N2feglO6HB17ZDT9bji8+jNvkNGcJQv7HXmHzmjEPyJtNMoYCJD+kZwrjfhc5ButW5p+ieCSJluXMwYOcVGCaKgsG2d0P8Jr5ZhIHPA+JE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714206278; c=relaxed/simple; bh=nGzpy7z61pVuCOHsnPdFSWn+Sd31DPmIOGC/vEAuGpI=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=MczGBpEsmZhDu6nCvOAVdseJzJxOexSxigvZfhOLiTzsKDnLOhK56DVl83KgLjnZuxc/8bZZ63D8HNqvgIEknXs9SaMMiRYXVesrlVpgBpR3V003agE8Z27f2jdFr0qFP86rOtMVZy3EZhwg2IteqDfpR9Z7/Lwy0tEvSepkWp4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-5723edf0ae5so3145580a12.0 for ; Sat, 27 Apr 2024 01:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714206275; x=1714811075; darn=sourceware.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=I3DsTl/zndD9nLWwLYfBkix6WmTzvZsonjDiSsgn9hE=; b=Lrcd8K2IcKhGEumA6IfPssp1Lg/vDipGHYOdlUvNc7Gfz3smIMW542G4cCTTkfKlMw NaFbGHububsuFM+F3K/UX2hj0b4nWkVL75mVq7RpPN1Q7whn23/DPLIjlmceoaIAJ1TZ MWD/QthD/fry0xyZJMah2ot6Wyey75s8vxc/KadYJue00GkcAXC5anoN9ChxIp8PxrZj ylHz5fL5dC4jQmrNy9O9yHFKTIZEAtLH0VVwWm1wYhIOYxFHic2P50jcTK0HeeUgWlMf P8dbo1qgEbbmXGVoCCDxewlP6uJ4L2Q5goazgtKcy44bwszejRJID93AHcDCCpr3L/Mg Deqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714206275; x=1714811075; 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=I3DsTl/zndD9nLWwLYfBkix6WmTzvZsonjDiSsgn9hE=; b=MtK7SW8rZVyQxKG9B5/8hlWJXdkTsBAaxAHvSU8IBsOzjOBvQbj50SqlhmtpNmVxkK a2O/tBDw4DrQB23fl7oqaLOQOh9ylTN+IWFu0nZwuGG4GeshZJB5v66d9PURu7/tsO8i a8jaQDVyfYgeh5UYwdnS2CoAScJ4Tp3NODgCFZ+SgrOi+T9lF6GshuFAgIBq+ZtYG0/6 1btlAVgfzfVAhYrYz5ZGLguy26sG58Dtr4DybjViRvSbmrhQpRicE1/LGbWJ/z7qS2qQ 8WIY3GMU8tEOTnf2zW3MS7uUMWFwDfKeWKnFYrKYB89Y187pT65aQH6RDG3I1n4XjbDi oPdQ== X-Gm-Message-State: AOJu0YzWvzNUvBlK1Vp4FNQZy8+HDWEWJe3rhpdlGog/HW5oK1XBhNhu SplirPUBJoVn0ylgnZO+z9GW9E71acpXfIFFoEulATpJW0TJ95RFZbwfJ6iMZFsAq1rAQRdWM9I EYnPpB+nWvOvvgZ74Ry2t/Mh6N1c= X-Google-Smtp-Source: AGHT+IHKzcJEMB0jrWl53dkyb2jX86vpts6EJTsSo7veTMAdGkszYG9orhzCZaYiyCHoq3l94j9GB7cx85k7z7NU3Ec= X-Received: by 2002:a50:935a:0:b0:572:5f61:387d with SMTP id n26-20020a50935a000000b005725f61387dmr1206891eda.11.1714206274673; Sat, 27 Apr 2024 01:24:34 -0700 (PDT) MIME-Version: 1.0 References: <20240425172019.863412-1-johan.sternerup@gmail.com> <87jzklgwig.fsf@tromey.com> <87frv9gvxk.fsf@tromey.com> <87le4zg97d.fsf@tromey.com> In-Reply-To: <87le4zg97d.fsf@tromey.com> From: Johan Sternerup Date: Sat, 27 Apr 2024 10:24:23 +0200 Message-ID: Subject: Re: [PATCH] Handle DAP "stepOut" request in outermost frame To: Tom Tromey Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Apr 26, 2024 at 10:28=E2=80=AFPM Tom Tromey wrote: > > >>>>> "Johan" =3D=3D Johan Sternerup writes: > > Johan> I think your suggestion to use background execution makes a lot > Johan> of sense. I'm not sure I've understood the details though. For > Johan> all the stepping commands we would have a request with > Johan> response=3DTrue and in_dap_thread=3DFalse, i.e. we would pass our > Johan> stepping command with a '&' to the gdb thread while waiting for > Johan> the response in the dap thread. > > Yes. > > Johan> Eventually the gdb thread would process the request and I guess > Johan> immediately return any error or success. Only after the step > Johan> request has been made can a stop event be triggered and since the > Johan> gdb thread is busy handling the request the _on_stop shouldn't be > Johan> allowed to run right? > ... > Johan> Are there maybe several gdb threads or are gdb events/commands > Johan> not processed in an event loop? > > The tricky case is a classic race: the gdb thread continues the > inferior, which immediately stops, causing gdb to emit a stop event, > which then causes the DAP event listener to generate a DAP event -- all > before the DAP function manages to return. > I think I get it now. The _on_stop() function might actually be called within the call chain from gdb.execute() when executing our request in the gdb thread. > So, somewhere we'd need a bit of code to ensure that stop events are > delayed, when necessary. > > This might be as simple as always calling send_event_later, and then > making send_event_later a little bit smarter so that it checks to see if > a request is "in flight". That information might already be available > due to the support for cancellation, though I'd have to re-read the code > to check. > It seems to me that by using the cancelation mechanism we're almost there. If I could utilize the locking provided by the CancellationHandler and the in_flight_dap_thread bool then I could use that in send_event_later() to ch= eck whether we should send the event immediately or just add it to delayed_even= ts. For this to work I would need to postpone clearing in_flight_dap_thread unt= il the result json has been passed to the write_queue. Basically that would me= an removing self.canceller.done() from _handle_command() and calling it after = the _send_json() call in the main_loop. I would also need to make delayed_events thread-safe so that it can be call= ed from the gdb thread. Does this sound like a reasonable way forward to you? > The event-generating code is in events.py. It's a bit messy, I'm > afraid. > > Tom