From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 3B0A03857702 for ; Wed, 3 May 2023 14:42:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3B0A03857702 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1683124955; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=HUuBlEZQbawQP+nxNXdvSeVw970HRPzmxSi8mbmCxzo=; b=X0wbs0uhmyiMt32ddGxuWlbRQbKPE8JMzm7eZ+weUrHc8CB4y8T8ggKharLXUErfx2xzrW HbCkpx/Rj2MjnUWe8NezyrnfG2ZdmUIuFk6ed6aBEUi6Q3z/0KL8jvvRWZB5rHeVaYRviE DwqAjeq+bG42EtbwjNDmoLM5aP90KZ0= Received: from mail-pj1-f70.google.com (mail-pj1-f70.google.com [209.85.216.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-300-volZK94MNZyqSjIWoLYOFA-1; Wed, 03 May 2023 10:42:34 -0400 X-MC-Unique: volZK94MNZyqSjIWoLYOFA-1 Received: by mail-pj1-f70.google.com with SMTP id 98e67ed59e1d1-24de504c5fcso4453223a91.2 for ; Wed, 03 May 2023 07:42:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683124953; x=1685716953; h=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=HUuBlEZQbawQP+nxNXdvSeVw970HRPzmxSi8mbmCxzo=; b=Rs9D4D8TOTObw39y/A7NO2tfmBU7q8V2CChnzk17EEOi6uJtypVW7TzL/9+pt+gCy8 nqgX3vJuds+xOk7a74murr8aEg8DSzTJ72zMMlY9dheIBHOjdSCEEnEFQ5oNMsSTZLTq l30H9YIiAzTy0WW+7AG9ZI1D8aYFVQucYsHitUq/J7JiWA6nL4hmw4O1n91jcgT4+IU7 twP3fmmuTK527jN5N6U9VYjXFDyaSUc4bWU6o5NAyx4TSuOYQYLWPe8S0OEMhqY1tsCf v+BYaf5zUCFh8eJ+X3Mvi668MJrSkLd6G6eenvV4iU7D4SoPiWpDNdZXvlRXz34eRnWx jNVg== X-Gm-Message-State: AC+VfDyLnQ1TQQ8QD8faYMWhMte6CVgWys8CJiptKJpFLFZuBzSII+yb zBZC76ktXZnVK9IOdwBF9V3Zk1wluAUbOkmQAnXVnl9Uyck36kcHtNqh9syhxyGzFQEYeFtjpSs mNM+guKxMJ/ZpYNTB9t0FjfEP8bS1EWD3IqxqOUUPI1rfkBF2 X-Received: by 2002:a17:90b:1094:b0:24d:e123:1eb2 with SMTP id gj20-20020a17090b109400b0024de1231eb2mr15266182pjb.37.1683124953361; Wed, 03 May 2023 07:42:33 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ653fQytjrJYhzsn3J0rgUDV2YzjvD57p3nieD8cajrUaVEqit69raBtPfKdrBEu3Eo7ETcWaG/NyxbHC+t400= X-Received: by 2002:a17:90b:1094:b0:24d:e123:1eb2 with SMTP id gj20-20020a17090b109400b0024de1231eb2mr15266169pjb.37.1683124953071; Wed, 03 May 2023 07:42:33 -0700 (PDT) MIME-Version: 1.0 References: <20230502205011.132151-1-simon.marchi@efficios.com> <20230502205011.132151-2-simon.marchi@efficios.com> In-Reply-To: <20230502205011.132151-2-simon.marchi@efficios.com> From: Alexandra Petlanova Hajkova Date: Wed, 3 May 2023 16:42:21 +0200 Message-ID: Subject: Re: [PATCH 01/30] gdb/mi: fix ^running record with multiple MI interpreters To: Simon Marchi Cc: gdb-patches@sourceware.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="000000000000f0e80f05facb10ec" X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: --000000000000f0e80f05facb10ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 2, 2023 at 10:50=E2=80=AFPM Simon Marchi via Gdb-patches < gdb-patches@sourceware.org> wrote: > I stumbled on the mi_proceeded and running_result_record_printed > globals, which are shared by all MI interpreter instances (it's unlikely > that people use multiple MI interpreter instances, but it's possible). > After poking at it, I found this bug: > > 1. Start GDB in MI mode > 2. Add a second MI interpreter with the new-ui command > 3. Use -exec-run on the second interpreter > > This is the output I get on the first interpreter: > > =3Dthread-group-added,id=3D"i1" > ~"Reading symbols from a.out...\n" > ~"New UI allocated\n" > (gdb) > =3Dthread-group-started,id=3D"i1",pid=3D"94718" > =3Dthread-created,id=3D"1",group-id=3D"i1" > ^running > *running,thread-id=3D"all" > > And this is the output I get on the second intepreter: > > =3Dthread-group-added,id=3D"i1" > (gdb) > -exec-run > =3Dthread-group-started,id=3D"i1",pid=3D"94718" > =3Dthread-created,id=3D"1",group-id=3D"i1" > *running,thread-id=3D"all" > > The problem here is that the `^running` reply to the -exec-run command > is printed on the wrong UI. It is printed on the first one, it should > be printed on the second (the one on which we sent the -exec-run). > > What happens under the hood is that captured_mi_execute_command, while > executing a command for the second intepreter, clears the > running_result_record_printed and mi_proceeded globals. > mi_about_to_proceed then sets mi_proceeded. Then, mi_on_resume_1 gets > called for the first intepreter first. Since the > > !running_result_record_printed && mi_proceeded > > condition is true, it prints a ^running, and sets > running_result_record_printed. When mi_on_resume_1 gets called for the > second interpreter, running_result_record_printed is already set, so > ^running is not printed there. > > It took me a while to understand the relationship between these two > variables. I think that in the end, this is what we want to track: > > 1. When executing an MI command, take note if that command causes a > "proceed". This is done in mi_about_to_proceed. > 2. In mi_on_resume_1, if the command indeed caused a "proceed", we want > to output a ^running record. And we want to remember that we did, > because... > 3. Back in captured_mi_execute_command, if we did not output a > ^running, we want to output a ^done. > > Moving those two variables to the mi_interp struture appears to fix it. > Only for the interpreter doing the -exec-run command does the > running_result_record_printed flag get cleared, and therefore only or > that one does the ^running record get printed. > > Add a new test for this, that does pretty much what the reproducer above > shows. Without the fix, the test fails because > mi_send_resuming_command_raw never sees the ^running record. > > Change-Id: I63ea30e6cb61a8e1dd5ef03377e6003381a9209b > > I can confirm the new test gdb.mi/run-with-two-mi-uis.exp, passes on ppc64le. --000000000000f0e80f05facb10ec--