This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] [PR 23660] On FreeBSD platform missing implementation of thread-db support


John,

Thanks for reviewing the patch.

> We could instead use libthread_db for now,

I tried to clean up the thread_db implementation (attached a diff file
for reference) as you suggested.
Please see if this needs further cleanup? All TLS test cases pass except below.

The test case "gdb.threads/tls-core.exp" fails with this new
implementation, I am yet to debug this.

I need some help in fixing "gdb.threads/staticthreads.exp" test case
where executable is "statically" linked.
For statically linked executable linkmap is NULL. How do we get link
map address?

Thanks
Rajendra


On Mon, Sep 17, 2018 at 10:41 PM, John Baldwin <jhb@freebsd.org> wrote:
> 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
>
>

Attachment: 0001-New-TLS-implementation-for-FreeBSD.patch
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]