From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118067 invoked by alias); 2 Feb 2019 15:52:19 -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 118059 invoked by uid 89); 2 Feb 2019 15:52:19 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:645, Hx-spam-relays-external:Sendmail, H*RU:Sendmail 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; Sat, 02 Feb 2019 15:52:18 +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 x12FqBNV026429 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 2 Feb 2019 10:52:16 -0500 Received: by simark.ca (Postfix, from userid 112) id 986221E882; Sat, 2 Feb 2019 10:52:11 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id D41081E472; Sat, 2 Feb 2019 10:52:09 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 02 Feb 2019 15:52:00 -0000 From: Simon Marchi To: John Baldwin Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 3/9] Handle TLS variable lookups when using separate debug object files. In-Reply-To: <6f24b813adb0155b499d6e2265a6f15a2db4e6ca.1548180889.git.jhb@FreeBSD.org> References: <6f24b813adb0155b499d6e2265a6f15a2db4e6ca.1548180889.git.jhb@FreeBSD.org> Message-ID: <27bfe45d3ccba5f52d2e3632da417000@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00009.txt.bz2 On 2019-01-22 13:42, John Baldwin wrote: > The object files stored in the shared object list are the original > object files, not the separate debug object files. However, when > resolving a TLS variable, the variable is resolved against a separate > debug object file if it exists. In this case, > svr4_fetch_objfile_link_map was failing to find the link map entry > since the debug object file is not in its internal list, only the > original object file. Does this solve an existing issue, or an issue that would come up with the following patches? Simon