This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] [PR 23660] On FreeBSD platform missing implementation of thread-db support
- From: John Baldwin <jhb at FreeBSD dot org>
- To: Rajendra SY <rajendra dot sy at gmail dot com>, gdb-patches at sourceware dot org
- Date: Mon, 17 Sep 2018 10:11:21 -0700
- Subject: Re: [PATCH] [PR 23660] On FreeBSD platform missing implementation of thread-db support
- References: <CAMAnt0=fYErrp--45kinNV1yx-FxP1hnqOCC_kuMt79vES5ROA@mail.gmail.com>
On 9/15/18 6:21 AM, Rajendra SY wrote:
> Problem:
> Missing libthread_db integration with GDB
>
> Cause:
> GDB missing libthread_db integration on FreeBSD target because of this
> GDB failed to access TLS variable values.
>
> Tests failed:
> - gdb.threads/tls-shared.exp
> - gdb.threads/tls-nodebug-pie.exp
> - gdb.threads/tls-so_extern.exp
> - gdb.threads/tls-var.exp
> - gdb.threads/tls.exp
> - gdb.threads/tls-core.exp
I'll have to take some time to review this. I had hoped to avoid using
libthread_db at all on FreeBSD (it doesn't support AVX or 32-bit processes
on 64-bit kernels, etc.). For TLS I was planning on teaching fbsd-tdep.c
about the various special variables libthread_db knows from rtld and libthr
and using that along with having each FreeBSD architecture provide the
thread pointer register to implement TLS.
We could instead use libthread_db for now, but if so I'd prefer to only use
libthread_db for TLS and not for anything else. This means that in theory
much of the proc-service API can be stubs that should never be called.
I would also be tempted to not have a separate thread-stratum target at all,
but just have the native target in fbsd-nat.c call into fbsd-thread-db as if
it was just a library for things like extra thread info (the pthread_t
pointer value) and TLS.
--
John Baldwin