From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32419 invoked by alias); 7 Feb 2019 05:05:05 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 32382 invoked by uid 89); 7 Feb 2019 05:05:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=figured X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 07 Feb 2019 05:05:03 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id x1754u5j013426 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 7 Feb 2019 00:05:01 -0500 Received: by simark.ca (Postfix, from userid 112) id 9A36B1E882; Thu, 7 Feb 2019 00:04:56 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id B7FD41E4B5; Thu, 7 Feb 2019 00:04:54 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 07 Feb 2019 05:05:00 -0000 From: Simon Marchi To: John Baldwin Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 5/9] Add a helper function to resolve TLS variable addresses for FreeBSD. In-Reply-To: References: Message-ID: <94e3c18ecfd67945d21926299a30dbde@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00050.txt.bz2 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). 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. 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. Simon