From: Andrew Burgess <aburgess@redhat.com>
To: "Aktemur, Tankut Baris" <tankut.baris.aktemur@intel.com>,
Pedro Alves <pedro@palves.net>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: RE: [PATCH] gdb: notify of inferior switch when needed from 'thread' command
Date: Mon, 03 Nov 2025 17:57:56 +0000 [thread overview]
Message-ID: <87ldkn578b.fsf@redhat.com> (raw)
In-Reply-To: <IA0PR11MB7307BB4B5B3CC3A354289261C4C7A@IA0PR11MB7307.namprd11.prod.outlook.com>
"Aktemur, Tankut Baris" <tankut.baris.aktemur@intel.com> writes:
> Hello Andrew,
>
>> I'd also like to draw you attention to the gdb/mi/* changes in this
>> patch as you didn't give your thoughts on that aspect of the change.
>>
>> That part of the patch handles the case where a user as an MI and CLI
>> interpreter running, and the inferior/thread changes as a result of an
>> MI action.
>>
>> In this case, the MI action might be a click, or miss-click in a UI, or
>> might even be some automated action by the MI frontend that the user
>> didn't (knowingly) perform. In this case, currently, the CLI will
>> receive a thread/frame change notification (i.e. the CLI interpreter
>> prints the new thread and frame), but the inferior notification is
>> missing. My patch changed GDB so the CLI would (when appropriate) also
>> receive an inferior changed notification, and so also print a "Switching
>> to inferior..." line.
>>
>> Surely in that case, your "the inferior change is known from the
>> command" argument doesn't apply, right?
>>
>> But then there's a whole argument about consistency. If I change
>> inferior and thread via the MI the CLI gets a "Switching to inferior"
>> line, but if I do the same switch via the CLI, I wouldn't. Which I
>> dislike.
>
> Something is not clear to me. Suppose there is an internal switch because
> of a breakpoint hit. E.g. My selected thread is 2.2. I resume all inferiors.
> Thread 1.1 hits a breakpoint. GDB switches. With your patch, the output is
>
> [Switching to Thread 0x7ffff7d85740 (LWP 1279258)]
>
> Thread 1.1 "test" hit Breakpoint ...
>
> Should we have seen a "Switching to inferior 1 ...", too?
Just to clarify, this behaviour is unchanged by my patch. But I'd
certainly think there's an argument to be made that the message should
be printed in this case.
For now, I'm just hoping that Pedro might get back to me as I'd like to
see the initial patch merged first.
Thanks,
Andrew
next prev parent reply other threads:[~2025-11-03 17:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-08 8:48 Andrew Burgess
2025-10-09 18:59 ` Pedro Alves
2025-10-10 14:47 ` Andrew Burgess
2025-11-03 16:12 ` Aktemur, Tankut Baris
2025-11-03 17:57 ` Andrew Burgess [this message]
2026-01-06 13:37 ` Andrew Burgess
2026-01-26 13:58 ` [PATCHv2] " Andrew Burgess
2026-03-17 19:41 ` Guinevere Larsen
2026-03-18 14:34 ` Andrew Burgess
2026-04-17 14:54 ` [PATCHv3] " Andrew Burgess
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ldkn578b.fsf@redhat.com \
--to=aburgess@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=pedro@palves.net \
--cc=tankut.baris.aktemur@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox