This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v2 1/7] Add target method for converting thread handle to thread_info struct pointer
- From: Kevin Buettner <kevinb at redhat dot com>
- To: Simon Marchi <simon dot marchi at polymtl dot ca>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 18 Jul 2017 17:01:26 -0700
- Subject: Re: [PATCH v2 1/7] Add target method for converting thread handle to thread_info struct pointer
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=kevinb at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 6124F7C84E
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6124F7C84E
- References: <20170408224959.67164a27@pinnacle.lan> <20170408230651.45120811@pinnacle.lan> <c4154c7df4895999f936b8e92d08a9eb@polymtl.ca>
On Thu, 04 May 2017 23:26:20 -0400
Simon Marchi <simon.marchi@polymtl.ca> wrote:
> On 2017-04-09 02:06, Kevin Buettner wrote:
> > --- a/gdb/linux-thread-db.c
> > +++ b/gdb/linux-thread-db.c
> > @@ -1410,6 +1410,29 @@ thread_db_extra_thread_info (struct target_ops
> > *self,
> > return NULL;
> > }
> >
> > +/* Return pointer to the thread_info struct which corresponds to
> > + THREAD_HANDLE (having length HANDLE_LEN). */
> > +static struct thread_info *
> > +thread_db_thread_handle_to_thread_info (struct target_ops *ops,
> > + const gdb_byte *thread_handle,
> > + int handle_len)
> > +{
> > + struct thread_info *tp;
> > + thread_t handle_tid;
> > +
> > + gdb_assert (handle_len == sizeof (handle_tid));
>
> I assume this is always true, because if you are using libthread_db, it
> implies that GDB is of the exact same architecture (32 bits vs 64 bits)
> as the inferior?
I'm about to submit a new patch set, but I decided that I ought to
address this question...
I had first thought that the answer to your question was "yes", but
after thinking about it some more, I decided that it's not appropriate
to generate an internal error (via a failed assert) for this case.
It's possible to get here via a call from the python interface. We
don't want user written code to generate internal errors. Therefore,
I changed it to call error() when there's a handle size mismatch.
Thanks for this review and all of the others too. They were very much
appreciated.
Kevin