From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29492 invoked by alias); 9 Aug 2019 18:16:39 -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 29443 invoked by uid 89); 9 Aug 2019 18:16:39 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=sites X-HELO: gateway23.websitewelcome.com Received: from gateway23.websitewelcome.com (HELO gateway23.websitewelcome.com) (192.185.50.161) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Aug 2019 18:16:37 +0000 Received: from cm13.websitewelcome.com (cm13.websitewelcome.com [100.42.49.6]) by gateway23.websitewelcome.com (Postfix) with ESMTP id 89716524F for ; Fri, 9 Aug 2019 13:16:36 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id w9RMhCVYp3Qi0w9RMhvF5L; Fri, 09 Aug 2019 13:16:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=lrIFShetqhaNZ3PT50ArU1yI/1Od562JsaaqPaqb4pw=; b=E+kf5A2sNSD2KjzxGbsO27YtCU VCY7ocffxlHEwSDTU/Bv5v+Zkobnac/iLxFeyarxFaDUhC6jnxjnoL9K5e2hv8pjsnuInt7f0MFO3 kWzr+nm0xrRqZqgw5fbxpG0ae; Received: from 97-122-178-82.hlrn.qwest.net ([97.122.178.82]:39814 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hw9RM-000HNT-9E; Fri, 09 Aug 2019 13:16:36 -0500 From: Tom Tromey To: Tom de Vries Cc: gdb-patches@sourceware.org, Jan Kratochvil Subject: Re: [PATCH][gdb] Fix gdb.dwarf2/amd64-entry-value-param.exp with -fPIE/-pie References: <20190809075424.GA15972@delia> Date: Fri, 09 Aug 2019 18:16:00 -0000 In-Reply-To: <20190809075424.GA15972@delia> (Tom de Vries's message of "Fri, 9 Aug 2019 09:54:26 +0200") Message-ID: <87h86q4324.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-08/txt/msg00234.txt.bz2 >>>>> "Tom" == Tom de Vries writes: Tom> Fix this by eliminating baseaddr from read_call_site_scope, and handling the Tom> relocation offset at the use sites in call_site_for_pc and Tom> call_site_to_target_addr. I like this approach, since it represents some small progress on the objfile splitting project. Tom> + { Tom> + struct obj_section *sec; Tom> + sec = find_pc_section (pc); Tom> + if (sec != NULL) Tom> + { Tom> + struct objfile *objfile = sec->objfile; Tom> + CORE_ADDR baseaddr Tom> + = ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT (objfile)); Why SECT_OFF_TEXT rather than the section "sec"? Tom> + CORE_ADDR pc_unrelocated Tom> + = gdbarch_adjust_dwarf2_addr (gdbarch, pc - baseaddr); I am not sure gdbarch_adjust_dwarf2_addr can be used "bidirectionally" like this. It is probably fine in practice but I wonder about the documented contract. Tom> + CORE_ADDR baseaddr Tom> + = ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT (objfile)); I guess this assumes the text section - but then can the call to find_pc_section give anything else? Maybe it's just something to comment and move on. Tom> - pc = attr_value_as_address (attr) + baseaddr; Tom> - pc = gdbarch_adjust_dwarf2_addr (gdbarch, pc); Tom> + pc = attr_value_as_address (attr); The approach taken elsewhere in dwarf2read.c is to bias, adjust, then unbias: CORE_ADDR low = (gdbarch_adjust_dwarf2_addr (gdbarch, best_lowpc + baseaddr) - baseaddr); Maybe this would be better here as well, or at least consistent. Tom