This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [MI non-stop 01/11] Report thread state in -thread-info output.
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: Vladimir Prus <vladimir at codesourcery dot com>
- Date: Mon, 14 Jul 2008 16:01:03 +0100
- Subject: Re: [MI non-stop 01/11] Report thread state in -thread-info output.
- References: <200806282034.58776.vladimir@codesourcery.com> <20080711134159.GC2651@caradoc.them.org> <g5c4d6$b9s$2@ger.gmane.org>
A Sunday 13 July 2008 06:38:50, Vladimir Prus wrote:
> Daniel Jacobowitz wrote:
> > On Sat, Jun 28, 2008 at 08:34:58PM +0400, Vladimir Prus wrote:
> >> + if (tp->state_ == THREAD_EXITED)
> >> + state = "exited";
> >
> > /* This field is internal to thread.c. Never access it directly,
> > use is_running instead. */
> > int state_;
> >
> > Aren't there accessors you can use here?
>
> Well, we talked with Pedro about this, I believe. The issue now is that
> is_xxx function take ptid, and do lookup. The right solution would be to
> have is_xxx_ptid functions taking ptid and is_xxx functions taking
> thread_info*.
>
> Pedro, does this approach seem OK for you, in the end?
Sure, that, or is_ptid_STATE/is_thread_STATE, or rename state_ to state
and allow access to it directly when we have a thread_info (or adding a
thread_state(thread_info) accessor and make the state enum public). The
main reason is_$(STATE) were introduced, the member was named state_ and
accessing it directly was noted as forbidden, was because of targets that
don't record the main thread.
Any approach taken is fine with me.
--
Pedro Alves