This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Inadvertently run inferior threads
- From: Doug Evans <dje at google dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Eli Zaretskii <eliz at gnu dot org>, gdb <gdb at sourceware dot org>
- Date: Mon, 22 Jun 2015 23:07:52 -0500
- Subject: Re: Inadvertently run inferior threads
- Authentication-results: sourceware.org; auth=none
- References: <83h9tq3zu3 dot fsf at gnu dot org> <55043A63 dot 6020103 at redhat dot com> <8361a339xd dot fsf at gnu dot org> <5504555C dot 804 at redhat dot com> <550458E0 dot 10206 at redhat dot com> <83y4jrsgui dot fsf at gnu dot org> <83ioaus6pt dot fsf at gnu dot org> <557ED083 dot 1060804 at redhat dot com> <83si9tngaj dot fsf at gnu dot org> <557EF27E dot 3030900 at redhat dot com>
On Mon, Jun 15, 2015 at 10:42 AM, Pedro Alves <palves@redhat.com> wrote:
>...
> With asynchronous control and background execution, you have to consider
> what happens if the user does "info threads" just while GDB is handling
> these internal stops. If the user does "step&" (step in the background,
> and give me the prompt right away), and then does "info threads" while the
> thread is busy doing the internal single-steps, it'd be highly
> confusing to sometimes see the thread as stopped (e.g., if it needed to
> be held a bit while another thread steps over a breakpoint) and sometimes
> as running.
I dunno if it'd be confusing.
Maybe we could give up on trying to cover up the stopped/running state
of the thread and just let info threads report something closer to
what's actually going on?
An asterisk or some such accompanying the output of threads in
intermediate states may be a sufficient clue to the the user.