From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id qn+PGteKMmrs2AsAWB0awg (envelope-from ) for ; Wed, 17 Jun 2026 07:53:59 -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=Grd7tftA; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 5BBD51E024; Wed, 17 Jun 2026 07:53:59 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.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 autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::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 6A0201E024 for ; Wed, 17 Jun 2026 07:53:58 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 940D64BAE7D5 for ; Wed, 17 Jun 2026 11:53:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 940D64BAE7D5 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=Grd7tftA Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 185D64BB3B83 for ; Wed, 17 Jun 2026 11:52:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 185D64BB3B83 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 185D64BB3B83 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=1781697152; cv=none; b=MWmN8nD78GgztpK46ESk2gUUoUacvnh0LIht8U9B5AJ3e14h3JE/qexn5McRWmmedBKrpTt7CugnmF43sTYJc1dNu9bNxgq6T2CatOmKlntvQ0jRayNySwchQJ0VL0DX/rUB4e+lbIfGTZ9vMyEalBMPwRml6o5Umag8AsG9GAA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1781697152; c=relaxed/simple; bh=1UrRVp8tz5bLnoqUuSdKIw40SdAK5OQgdvkCkcHM8Vw=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=DfUKLQHb8gdHGv6dSshtzsNWXC2Bzdt6kX6xlLjyIJJve7TbwCmMlyORuAoHKgmHPhTbPf+VKXaO07s96GR0BQ+DsloB7Zpuy5hiHfuEWBtcwkeZa2u3Ic+QJYk7RUsSDX2tnxzrLzp+eF+wbTLi03h4ba/9jTVGZ+p14oVGGuk= 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=Grd7tftA DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 185D64BB3B83 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 1wZooo-0004uc-5a; Wed, 17 Jun 2026 07:52:30 -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=buf0aKKstGo6Ty1xw/MDfpcERZbTkSm7sdeaU9z3TX8=; b=Grd7tftA6JFZ bi5coPmHvLc8gOjcuxdhflrTvKfQBA+sTuVUImxXaLG+sxoZcS/Pjo39/cl3TVIQnukuIMvVmdH2w 3ZPtOvt6WZKk+p7thIqjz1HAPeO1lsJe/Xc9BfwjtEye+zQOAyqc+Lj1+l8phY0DSYrrHtj9bHKKu 1dPxXGSNwq9xuY/n/RE4BzSLnPwCLGBKTqSYKguzvfyNUwWWDb/MsZQSz++1SCFJvPf2lNu2ser2Y GBwnf1P4q+PWQyQcR7KNIxOvSfAPo17fDmz0XTKxDnqhpiS7x2pmP9Hty4kv+iNSMUUPuyyOjxKe5 UHS9vlXNlC8LCyYkKYJbnw==; Date: Wed, 17 Jun 2026 14:52:27 +0300 Message-Id: <8633yljsec.fsf@gnu.org> From: Eli Zaretskii To: Andrew Burgess Cc: gdb-patches@sourceware.org, guinevere@redhat.com, pedro@palves.net In-Reply-To: (message from Andrew Burgess on Tue, 16 Jun 2026 20:47:15 +0100) Subject: Re: [PATCHv3 2/4] gdb: introduce program_space::get_entry_point_info function References: 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: Guinevere Larsen , > Pedro Alves , > Andrew Burgess , > Eli Zaretskii > Date: Tue, 16 Jun 2026 20:47:15 +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, uses > the AT_BASE auxv entry and the entry address pulled from the ELF > header to compute the inferior 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. > > Reviewed-By: Eli Zaretskii > --- > gdb/NEWS | 7 + > gdb/doc/gdb.texinfo | 22 +++ > gdb/frame.c | 10 +- > gdb/progspace.c | 60 ++++++++ > gdb/progspace.h | 48 ++++++ > gdb/solib-svr4.c | 85 +++++++++++ > gdb/solib-svr4.h | 1 + > gdb/solib.h | 14 ++ > gdb/testsuite/gdb.base/bt-after-starti.exp | 167 +++++++++++++++++++++ > gdb/testsuite/lib/gdb.exp | 8 + > 10 files changed, 417 insertions(+), 5 deletions(-) > create mode 100644 gdb/testsuite/gdb.base/bt-after-starti.exp Thanks, the documentation parts are okay. Reviewed-By: Eli Zaretskii