From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66135 invoked by alias); 7 Mar 2019 16:08:58 -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 66119 invoked by uid 89); 7 Mar 2019 16:08:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=Permit, HX-Languages-Length:1278, conceptually, familiar X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 07 Mar 2019 16:08:57 +0000 Received: from [172.16.0.89] (192-222-157-41.qc.cable.ebox.net [192.222.157.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 039B31E4A5; Thu, 7 Mar 2019 11:08:54 -0500 (EST) Subject: Re: [PATCH v2 04/11] Add a new gdbarch method to resolve the address of TLS variables. To: John Baldwin , gdb-patches@sourceware.org References: <4db33aead3f31532b7d4e165d9786df792a4d925.1549672588.git.jhb@FreeBSD.org> From: Simon Marchi Message-ID: <02c8a44b-b1d2-0f0f-9b6f-72a0fb673f83@simark.ca> Date: Thu, 07 Mar 2019 16:08:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <4db33aead3f31532b7d4e165d9786df792a4d925.1549672588.git.jhb@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2019-03/txt/msg00150.txt.bz2 On 2019-02-08 7:40 p.m., John Baldwin wrote: > Permit TLS variable addresses to be resolved purely by an ABI rather > than requiring a target method. This doesn't try the target method if > the ABI function is present (even if the ABI function fails) to > simplify error handling. I don't see anything wrong with the patch (and the comment you removed in target_translate_tls_address hints it is right), but again I am not very familiar with how TLS works, so I wouldn't spot if anything was conceptually wrong with this approach. I would appreciate if another maintainer could take a look and give their opinion. > diff --git a/gdb/gdbarch.sh b/gdb/gdbarch.sh > index afc4da7cdd..09097bcbaf 100755 > --- a/gdb/gdbarch.sh > +++ b/gdb/gdbarch.sh > @@ -602,6 +602,7 @@ m;int;remote_register_number;int regno;regno;;default_remote_register_number;;0 > > # Fetch the target specific address used to represent a load module. > F;CORE_ADDR;fetch_tls_load_module_address;struct objfile *objfile;objfile > +M;CORE_ADDR;get_thread_local_address;ptid_t ptid, CORE_ADDR lm_addr, CORE_ADDR offset;ptid, lm_addr, offset Could you document the method, especially the meaning of the parameters? Simon