Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: John Baldwin <jhb@FreeBSD.org>
To: gdb-patches@sourceware.org
Subject: Re: [PATCH 5/9] Add a helper function to resolve TLS variable addresses for FreeBSD.
Date: Thu, 24 Jan 2019 17:09:00 -0000	[thread overview]
Message-ID: <e88913dc-81fd-a709-9877-22330dd877b9@FreeBSD.org> (raw)
In-Reply-To: <f09cffd4714ca17c5fcbc6ad7c9ec5e5dd649bd7.1548180889.git.jhb@FreeBSD.org>

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).

-- 
John Baldwin

                                                                            


  reply	other threads:[~2019-01-24 17:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-22 18:43 [PATCH 0/9] Support for thread-local variables on FreeBSD John Baldwin
2019-01-22 18:43 ` [PATCH 3/9] Handle TLS variable lookups when using separate debug object files John Baldwin
2019-02-02 15:52   ` Simon Marchi
2019-02-04 20:02     ` John Baldwin
2019-02-05 20:06       ` Simon Marchi
2019-02-05 22:21         ` John Baldwin
2019-02-05 22:33           ` John Baldwin
     [not found]             ` <67973931006085a171ad69952649de33@polymtl.ca>
2019-02-07  4:08               ` Simon Marchi
2019-01-22 18:43 ` [PATCH 9/9] Support TLS variables on FreeBSD/powerpc John Baldwin
2019-01-22 18:43 ` [PATCH 1/9] Support the fs_base and gs_base registers on i386 John Baldwin
2019-01-27  4:22   ` Simon Marchi
2019-01-28 17:54     ` John Baldwin
2019-02-02 15:11       ` Simon Marchi
2019-01-22 18:43 ` [PATCH 7/9] Support TLS variables on FreeBSD/i386 John Baldwin
2019-01-22 18:43 ` [PATCH 6/9] Support TLS variables on FreeBSD/amd64 John Baldwin
2019-01-22 18:43 ` [PATCH 2/9] Support fs_base and gs_base on FreeBSD/i386 John Baldwin
2019-02-02 15:26   ` Simon Marchi
2019-02-04 19:45     ` John Baldwin
2019-02-05 18:59       ` Simon Marchi
2019-01-22 18:52 ` [PATCH 4/9] Add a new gdbarch method to resolve the address of TLS variables John Baldwin
2019-01-22 18:52 ` [PATCH 8/9] Support TLS variables on FreeBSD/riscv John Baldwin
2019-01-27 23:35   ` Andrew Burgess
2019-01-22 18:52 ` [PATCH 5/9] Add a helper function to resolve TLS variable addresses for FreeBSD John Baldwin
2019-01-24 17:09   ` John Baldwin [this message]
2019-02-07  5:05     ` Simon Marchi
2019-02-07 17:02       ` John Baldwin
2019-02-09  0:34         ` John Baldwin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e88913dc-81fd-a709-9877-22330dd877b9@FreeBSD.org \
    --to=jhb@freebsd.org \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox