From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id PsamFUmiK2qkugIAWB0awg (envelope-from ) for ; Fri, 12 Jun 2026 02:08:09 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=Te+fNuXu; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 4445B1E098; Fri, 12 Jun 2026 02:08:09 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id B5C681E024 for ; Fri, 12 Jun 2026 02:08:06 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A1B5D4BA23C4 for ; Fri, 12 Jun 2026 06:07:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A1B5D4BA23C4 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=Te+fNuXu Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id EC3934BA2E09 for ; Fri, 12 Jun 2026 06:07:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EC3934BA2E09 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org EC3934BA2E09 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1781244453; cv=none; b=kB+RhDLWn+Ae6wPnqZi7N6YNtVi2tkvlHUrjeiOgemO2e3fjn5dr2b6d38tXKqO6JU5XEk/bN+nXejlzLHf5a8AEVDJ4B/1eaY7EikuqWOJUGsg059ZdLWCRBbxPy70rwFDKljd2ig8vGh1LkL9WAtz4YsArx/x77r8Xg4iN/qA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1781244453; c=relaxed/simple; bh=ejokdO9ksnOjybTQCaBaqEgC6sn4oZnSQYpNx9cjSJo=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=Y2+6Bc3Eb8196Z8aDq2SfQhm9KBXqRrNn1b/y1ZFJtS3qlbDWefD1RB4RLU1evRR39fqnm0zdo3QFKjF9FBvzs3PyVqEabtuObzOzISeCmRJkiZ1vQh8p7mOH2h3VBPDJNs+WX1SxkOxBP2mDrTYy/5SUStCz+2B5pDeSd07+qA= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=Te+fNuXu DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EC3934BA2E09 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wXv3C-0005Cx-Po; Fri, 12 Jun 2026 02:07:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=faxzaUBUzDITHb8PTT0aVcePgZERLaGKWsfxOLLCMW8=; b=Te+fNuXuqc+I 9hJ27QZ3gaRJdm5vKqmhkAjnuD50OeNJozwiOZcv2rIsmt5ckaYi0RED7ArdPMHgklGre5TRTiyvQ HQdZis6oJosVKQ0DCUKoWeqCfyj7hmcKBYM8preWN/8ha/bpGS+WgN0yNfGoGrI52EA9Etdsc70pO rCefaU3aVbMupctL4W+6I+r3p6Px17H87C2jtQzRzackR36nh2j0Mzn5vojfe9u7TLi3T0KoaPo0q 0wKAuIvbVSks8beIgl8RlHgNVVgT1XI5mpetUl2mhekjmRPTrUQLpjkEUxRlF4PDQNrslMtKEI2h7 pPIrKOlftMvrEsqP9HBVVw==; Date: Fri, 12 Jun 2026 09:07:27 +0300 Message-Id: <86ecicnvfk.fsf@gnu.org> From: Eli Zaretskii To: Andrew Burgess Cc: gdb-patches@sourceware.org In-Reply-To: <864cefb52d208dd8aac6b1b5f452cadad7546af8.1781214731.git.aburgess@redhat.com> (message from Andrew Burgess on Thu, 11 Jun 2026 22:59:05 +0100) Subject: Re: [PATCHv2 2/3] gdb: introduce program_space::get_entry_point_info function References: <41fe591d58ba010fa771e80ca674b61e30feef2f.1780942441.git.aburgess@redhat.com> <864cefb52d208dd8aac6b1b5f452cadad7546af8.1781214731.git.aburgess@redhat.com> X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org > From: Andrew Burgess > Cc: Andrew Burgess > Date: Thu, 11 Jun 2026 22:59:05 +0100 > > I noticed that when debugging a dynamically linked executable, if I > started the inferior with 'starti' then used 'bt' I would see some > bogus frames: > > (gdb) starti > Starting program: /tmp/hello > > Program stopped. > 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2 > (gdb) bt > #0 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2 > #1 0x0000000000000001 in ?? () > #2 0x00007fffffffac13 in ?? () > #3 0x0000000000000000 in ?? () > (gdb) > > This surprised me as 'backtrace past-entry' was off: > > (gdb) show backtrace past-entry > Whether backtraces should continue past the entry point of a program is off. > > I was expecting GDB to stop the backtrace at the inferior's entry > address. > > Frame unwinding starts in get_prev_frame, and in here we find this > block: > > if (this_frame->level >= 0 > && get_frame_type (this_frame) == NORMAL_FRAME > && !user_set_backtrace_options.backtrace_past_entry > && frame_pc.has_value () > && inside_entry_func (this_frame)) > { > frame_debug_got_null_frame (this_frame, "inside entry func"); > return NULL; > } > > Which uses inside_entry_func to terminate the backtrace when we reach > the entry frame. The inside_entry_func function calls > current_program_space->exec_entry_point_address_if_available and uses > the result to figure out if we are in the entry frame. > > And here the problem becomes obvious, we are only checking if we are > in the "entry frame" for the main executable, not for the inferior as > a whole. And indeed, if I compile the same test program as a static > binary, where there will be no run-time linker, and the entry point of > the executable is the entry point for the inferior, then the 'bt' > problem I saw above goes away. > > This suggests, I think, that we need to track two different entry > addresses, the entry address for the executable file, and the entry > address for the entire inferior. Then, for dynamically linked > executables, these two addresses can be different, the former will > still be the same address within the main executable file, while the > latter will be the address of the entry point within the run-time > linker. > > If we had this information then we could extend inside_entry_func to > check both addresses, and the 'bt' problem seen above will be > resolved. > > To make this information available I added a new solib_ops method, > solib_ops::inferior_entry_point_address, for svr4 targets this figures > out if the main executable is dynamically linked, and if it is, finds > the run-time linker and uses that to compute the entry address. > > I then added program_space::get_entry_point_info, which returns a > struct containing the two entry point addresses, one comes from the > new solib_ops method, and one comes from the existing method > program_space::exec_entry_point_address_if_available. > > With the infrastructure in place I can then update inside_entry_func > to check against both entry addresses. > > To aid in debugging GDB, I added a new maintenance command: > > maintenance info entry-address > > which just calls program_space::get_entry_point_info and then prints > the two addresses. I left this as a maintenance command as I don't > see much user utility in this right now, but it made it easier for me > to see what GDB was doing, so I left the command in this commit. > --- > gdb/NEWS | 7 + > gdb/doc/gdb.texinfo | 14 ++ > gdb/frame.c | 10 +- > gdb/progspace.c | 60 ++++++++ > gdb/progspace.h | 48 +++++++ > gdb/solib-svr4.c | 102 ++++++++++++++ > gdb/solib-svr4.h | 1 + > gdb/solib.h | 14 ++ > gdb/testsuite/gdb.base/bt-after-starti.exp | 153 +++++++++++++++++++++ > 9 files changed, 404 insertions(+), 5 deletions(-) > create mode 100644 gdb/testsuite/gdb.base/bt-after-starti.exp > > diff --git a/gdb/NEWS b/gdb/NEWS > index d5214a98a57..99c9fb6999c 100644 > --- a/gdb/NEWS > +++ b/gdb/NEWS > @@ -146,6 +146,13 @@ disable skip > These are new aliases for 'skip delete', 'skip enable', and 'skip > disable' respectively. > > +maint info entry-address > + Display the inferior and main executable entry addresses for the > + current inferior. The inferior entry address is the address of the > + first instruction in the inferior that was executed. The main > + executable entry address is the address of the first instruction in > + the main executable that was executed. > + > * MI changes > > ** The "-trace-save" command no longer supports the "-ctf" flag. > diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo > index a698b2b8451..dd6cfd04011 100644 > --- a/gdb/doc/gdb.texinfo > +++ b/gdb/doc/gdb.texinfo > @@ -43212,6 +43212,20 @@ Maintenance Commands > Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M > Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M > @end smallexample > + > +@kindex maint info entry-address > +@item maint info entry-address > +Display the entry addresses for the currently selected inferior. Two > +addresses are displayed, the first is the address of the first > +instruction in the inferior, and the second is for the first > +instruction in the main executable, see @kbd{file} in @ref{Files, > +,Commands to Specify Files}. > + > +For statically linked inferiors, these addresses will usually be the > +same, but for dynamically linked executables these addresses can be > +different, with the inferior's entry address being an address within > +the run-time linker, while the main executable's entry address will > +always be an address within the executable file. > @end table Thanks, the documentation parts are okay. Although I would suggest to perhaps clarify the description in the manual by explaining how these addresses are related to the first instruction in the 'main' function of the program. As written, the description is highly-technical, and I think it will only be clear enough for people who are intimately familiar with the program's startup code on different systems. Reviewed-By: Eli Zaretskii