From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id B5DFC3858D28 for ; Mon, 4 Oct 2021 16:47:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B5DFC3858D28 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id EB90B20236; Mon, 4 Oct 2021 16:47:14 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id B710413A83; Mon, 4 Oct 2021 16:47:14 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id DE5hKRIwW2EzQQAAMHmgww (envelope-from ); Mon, 04 Oct 2021 16:47:14 +0000 Subject: Re: [PATCH 4/4] [gdb/symtab] Use unrelocated addresses in call_site To: Simon Marchi Cc: gdb-patches@sourceware.org References: <20211001123328.22314-1-tdevries@suse.de> <20211001123328.22314-4-tdevries@suse.de> <82e1a4ada2d2fbef2b436f707c9cf435@polymtl.ca> From: Tom de Vries Message-ID: <86b11c90-1487-f12e-6003-9db846253476@suse.de> Date: Mon, 4 Oct 2021 18:47:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <82e1a4ada2d2fbef2b436f707c9cf435@polymtl.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP 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: 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: , X-List-Received-Date: Mon, 04 Oct 2021 16:47:16 -0000 On 10/1/21 10:56 PM, Simon Marchi wrote: > On 2021-10-01 08:33, Tom de Vries via Gdb-patches wrote: >> From: Simon Marchi >> >> Consider test-case gdb.trace/entry-values.exp with target board >> unix/-fPIE/-pie. >> >> Using this command we have an abbreviated version, and can see the >> correct >> @entry values for foo: >> ... >> $ gdb -q -batch outputs/gdb.trace/entry-values/entry-values \ >>   -ex start \ >>   -ex "break foo" \ >>   -ex "set print entry-values both" \ >>   -ex continue >> Temporary breakpoint 1 at 0x679 >> >> Temporary breakpoint 1, 0x0000555555554679 in main () >> Breakpoint 2 at 0x55555555463e >> >> Breakpoint 2, 0x000055555555463e in foo (i=0, i@entry=2, j=2, j@entry=3) >> ... >> >> Now, let's try the same again, but run directly to foo rather than >> stopping at >> main: >> ... >> $ gdb -q -batch outputs/gdb.trace/entry-values/entry-values \ >>   -ex "break foo" \ >>   -ex "set print entry-values both" \ >>   -ex run >> Breakpoint 1 at 0x63e >> >> Breakpoint 1, 0x000055555555463e in foo (i=0, i@entry=, \ >>   j=2, j@entry=) >> ... >> >> So, what explains the difference?  Noteworthy, this is a dwarf assembly >> test-case, with debug info for foo and bar, but not for main. >> >> In the first case: >> - we run to main >> - this does not trigger expanding debug info, because there's none for >> main >> - we set a breakpoint at foo >> - this triggers expanding debug info.  Relocated addresses are used in >>   call_site info (because the exec is started) >> - we continue to foo, and manage to find the call_site info >> >> In the second case: >> - we set a breakpoint at foo >> - this triggers expanding debug info.  Unrelocated addresses are used in >>   call_site info (because the exec is not started) >> - we run to foo >> - this triggers objfile_relocate1, but it doesn't update the call_site >>   info addresses >> - we don't manage to find the call_site info > > Thanks for this explanation, I had not realized the difference in > behavior here. > > The patch LGTM. Thanks for the review. Committed. Thanks, - Tom