This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 5/9] Add a helper function to resolve TLS variable addresses for FreeBSD.
- From: John Baldwin <jhb at FreeBSD dot org>
- To: Simon Marchi <simon dot marchi at polymtl dot ca>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 7 Feb 2019 09:02:18 -0800
- Subject: Re: [PATCH 5/9] Add a helper function to resolve TLS variable addresses for FreeBSD.
- References: <cover.1548180889.git.jhb@FreeBSD.org> <f09cffd4714ca17c5fcbc6ad7c9ec5e5dd649bd7.1548180889.git.jhb@FreeBSD.org> <e88913dc-81fd-a709-9877-22330dd877b9@FreeBSD.org> <94e3c18ecfd67945d21926299a30dbde@polymtl.ca>
On 2/6/19 9:04 PM, Simon Marchi wrote:
> On 2019-01-24 12:08, John Baldwin wrote:
>> On 1/22/19 10:42 AM, John Baldwin wrote:
>>> The fbsd_get_thread_local_address function accepts the base address of
>>> a thread's DTV array and the base address of an object file's link map
>>> and uses this to compute a TLS variable's address. FreeBSD
>>> architectures use an architecture-specific method to determine the
>>> address of the DTV array pointer and call this helper function to
>>> perform the rest of the address calculation.
>>>
>>> * fbsd-tdep.c (fbsd_pspace_data_handle): New variable.
>>> (struct fbsd_pspace_data): New type.
>>> (get_fbsd_pspace_data, fbsd_pspace_data_cleanup)
>>> (fbsd_read_integer_by_name, fbsd_fetch_rtld_offsets)
>>> (fbsd_get_tls_index, fbsd_get_thread_local_address): New function.
>>> (_initialize_fbsd_tdep): Initialize 'fbsd_pspace_data_handle'.
>>> * fbsd-tdep.c (fbsd_get_thread_local_address): New prototype.
>>> ---
>>> gdb/ChangeLog | 10 ++++
>>> gdb/fbsd-tdep.c | 146
>>> ++++++++++++++++++++++++++++++++++++++++++++++++
>>> gdb/fbsd-tdep.h | 10 ++++
>>> 3 files changed, 166 insertions(+)
>>>
>>> diff --git a/gdb/fbsd-tdep.c b/gdb/fbsd-tdep.c
>>> index d971d3a653..2e0f72d17b 100644
>>> --- a/gdb/fbsd-tdep.c
>>> +++ b/gdb/fbsd-tdep.c
>>> +
>>> +/* Lookup offsets of fields in the runtime linker's 'Obj_Entry'
>>> + structure needed to determine the TLS index of an object file. */
>>> +
>>> +static void
>>> +fbsd_fetch_rtld_offsets (struct gdbarch *gdbarch, struct
>>> fbsd_pspace_data *data)
>>> +{
>>> + TRY
>>> + {
>>> + /* Fetch offsets from debug symbols in rtld. */
>>> + data->off_linkmap = parse_and_eval_long ("&((Obj_Entry
>>> *)0)->linkmap");
>>> + data->off_tlsindex = parse_and_eval_long ("&((Obj_Entry
>>> *)0)->tlsindex");
>>> + data->rtld_offsets_valid = true;
>>> + return;
>>
>> I'm not really happy about using parse_and_eval_long with an open-coded
>> equivalent of offsetof() here. It seems we don't already have existing
>> functionality for this though? I think I could use 'lookup_struct' to
>> find
>> the 'struct type *' for 'Obj_Entry', but if I used
>> 'lookup_struct_elt_type'
>> to get the type of an element that doesn't give me anything that has
>> the
>> offset. We could perhaps instead add a new function
>> 'lookup_struct_elt_offset'
>> that took the element name as a string and figured out the offset. We
>> could
>> then use this to provide an 'offsetof' builtin for the C language
>> perhaps.
>> However, I suspect that lookup_struct_elt_offset would have to invoke a
>> language-specific function to do the actual computation (just as ptype
>> /o
>> handling is language-specific).
>
> Doesn't parse_and_eval_long also call in language-specific things? The
> expression is parsed according to whatever is the current language, I
> suppose. If needed, I guess we could change temporarily the current
> language to C, which is the language the dynamic linker is written in
> (until proven otherwise).
Mmm, that's true.
> The offset of fields within structures is available (see macro
> FIELD_BITPOS). I haven't looked too deep into it, but it sounds like it
> should be possible to implement what you need with that.
Hmm. When I looked at the code for ptype /o it seemed to keep a running
tally for the byte offset. It wasn't clear to me if perhaps FIELD_BITPOS
was for bitfields and the bit offset within a byte/word. However, the
Linux kernel patch series does have some code to do this. I could perhaps
steal from that to implement lookup_struct_elt_offset. I would probably
make it support nested fields as well (I think the Linux kernel patches are
using it for some nested fields).
> One question: does this work only when you have debug info for the
> dynamic linker data structures? Will debug info always be available?
> On some Linux distributions, for example, I think it's rather common to
> not have the debug info for the system libraries (libc, libpthread) by
> default.
Yes, this requires debug symbols. Recent releases of FreeBSD do include an
option to install them by default, but they are not always present. I will
probably add global variables in rtld itself similar to the ones inside of
the thread library and then update GDB to fetch those instead once I've done
that. I just haven't patched the runtime linker yet for that.
--
John Baldwin