From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.baldwin.cx (bigwig.baldwin.cx [66.216.25.90]) by sourceware.org (Postfix) with ESMTPS id 61E2F3853804; Wed, 23 Mar 2022 21:00:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 61E2F3853804 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=FreeBSD.org Received: from ralph.com (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 89E351A84C72; Wed, 23 Mar 2022 17:00:54 -0400 (EDT) From: John Baldwin To: binutils@sourceware.org, gdb-patches@sourceware.org Subject: [PATCH 01/12] Handle another edge case for TLS variable lookups. Date: Wed, 23 Mar 2022 14:00:40 -0700 Message-Id: <20220323210048.25525-2-jhb@FreeBSD.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220323210048.25525-1-jhb@FreeBSD.org> References: <20220323210048.25525-1-jhb@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (mail.baldwin.cx [0.0.0.0]); Wed, 23 Mar 2022 17:00:54 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.103.1 at mail.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00, FORGED_SPF_HELO, GIT_PATCH_0, KAM_DMARC_STATUS, KHOP_HELO_FCRDNS, SPF_HELO_PASS, SPF_SOFTFAIL, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2022 21:00:56 -0000 This is similar to the change in df22c1e5d53c38f38bce6072bb46de240f9e0e2b but applies to the main object file. The original change I encountered when testing TLS on RISC-V for which I was unable to test TLS variables in the main executable due to issues with compiler-generated debug info, so I only checked for a backlink before walking the list of shared library object files. However, I ran into this issue again (of a separate debug object file being passed to svr4_fetch_objfile_link_map) when testing TLS variables on 32-bit arm. To fix, move the check for a backlink earlier before the check for the main object file. --- gdb/solib-svr4.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c index 69f2991f5e6..aba476f6cf2 100644 --- a/gdb/solib-svr4.c +++ b/gdb/solib-svr4.c @@ -1449,15 +1449,15 @@ svr4_fetch_objfile_link_map (struct objfile *objfile) if (info->main_lm_addr == 0) solib_add (NULL, 0, auto_solib_add); - /* svr4_current_sos() will set main_lm_addr for the main executable. */ - if (objfile == current_program_space->symfile_object_file) - return info->main_lm_addr; - /* If OBJFILE is a separate debug object file, look for the original object file. */ if (objfile->separate_debug_objfile_backlink != NULL) objfile = objfile->separate_debug_objfile_backlink; + /* svr4_current_sos() will set main_lm_addr for the main executable. */ + if (objfile == current_program_space->symfile_object_file) + return info->main_lm_addr; + /* The other link map addresses may be found by examining the list of shared libraries. */ for (struct so_list *so : current_program_space->solibs ()) -- 2.34.1