From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id zxqgF1BhVmH5awAAWB0awg (envelope-from ) for ; Thu, 30 Sep 2021 21:16:00 -0400 Received: by simark.ca (Postfix, from userid 112) id 4FB7E1EDDB; Thu, 30 Sep 2021 21:16:00 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 912061E813 for ; Thu, 30 Sep 2021 21:15:59 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 163473857C4F for ; Fri, 1 Oct 2021 01:15:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 163473857C4F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1633050959; bh=xOfMnEjDS5Ro20VH+rdgDK2ffbOQpdVaam7ZHQY6r0E=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=Xn+rZhdzn7HnnEPg+6GSS7n/QuTAxyKfYw3oh9mgbyV1OL8ln1mEp6faUHcATPsN0 WelyWVUIBMzy9cVPMuYKOHYF2WJBBIE3wnh91A4wc3ML9Ady064PtaarwVxR5QUflf 6S8SZEKhGstwRbld5Gg5ONYZuszmjMg8OL8Qse5s= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 88D073858C39 for ; Fri, 1 Oct 2021 01:15:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 88D073858C39 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 1911FYDN024163 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Sep 2021 21:15:39 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 1911FYDN024163 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 0C6A51E813; Thu, 30 Sep 2021 21:15:33 -0400 (EDT) Message-ID: <80671fa7-d3cf-d518-a53b-f3ed8e453576@polymtl.ca> Date: Thu, 30 Sep 2021 21:15:33 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.1 Subject: Re: [PATCH][gdb/symtab] Relocate call_site_htab Content-Language: en-US To: Tom de Vries , gdb-patches@sourceware.org References: <20210930095608.GA11467@delia> <5940137d-6a6f-2309-673f-d9491ed654b5@polymtl.ca> <9a605b9e-267b-e9f5-4122-c407913e92f7@suse.de> In-Reply-To: <9a605b9e-267b-e9f5-4122-c407913e92f7@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Fri, 1 Oct 2021 01:15:34 +0000 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Cc: Tom Tromey Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > Ack, thanks. I've put this through testing and ran into only two > regressions (so, this used to pass for me with unix/-fPIE/-pie): > ... > FAIL: gdb.trace/entry-values.exp: bt (1) (pattern 1) > FAIL: gdb.trace/entry-values.exp: bt (2) (pattern 1) > ... > while still fixing all the unix/-fno-PIE/-no-pie vs unix/-fPIE/-pie > regressions. > > Fixed by: > ... > diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c > index bb5767aae67..fa775722afb 100644 > --- a/gdb/dwarf2/read.c > +++ b/gdb/dwarf2/read.c > @@ -13517,7 +13517,8 @@ read_call_site_scope > sect_offset_str (die->sect_off), objfile_name > (objfile)); > else > { > - lowpc = gdbarch_adjust_dwarf2_addr (gdbarch, lowpc + > baseaddr); > + lowpc = (gdbarch_adjust_dwarf2_addr (gdbarch, lowpc + > baseaddr) > + - baseaddr); > SET_FIELD_PHYSADDR (call_site->target, lowpc); > } > } That makes sense. This means that with my patch, the value stored in the target was relocated, by interpreted as unrelocated? Does that mean that with your patch, that value ended up relocated twice? Once here, and once in objfile_relocate1? Simon