From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id enkfMrPQL2oVIwgAWB0awg (envelope-from ) for ; Mon, 15 Jun 2026 06:15:15 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=cnYZv9ki; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id AFCBF1E024; Mon, 15 Jun 2026 06:15:15 -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 98D161E024 for ; Mon, 15 Jun 2026 06:15:14 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A665B4C31814 for ; Mon, 15 Jun 2026 10:15:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A665B4C31814 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=cnYZv9ki Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 609374BB8F60 for ; Mon, 15 Jun 2026 10:14:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 609374BB8F60 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 609374BB8F60 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1781518485; cv=none; b=u04XzeQWuNCDIO48fb1OGHnmIohZtHh+8p9v4kFn1v7FuTxU/rkxTnFuzXyoY2uW68q49TKhXiq7V4wAu3ptrzpK1kb5sGfk/npwT1o9QgdZVysvZv8QAhPNaMAq4fAoqYjwtIgq8ocvCxWwvd0wcozv8cxg9h3VENv02kglhlc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1781518485; c=relaxed/simple; bh=phpAhMA31iIEkMrneUtHk6bMuHreooPMYH3FvzFvlWo=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=JLmflE8XA7v7WlyYdqzBrsfetAjwjhPsyTn4XrRTbTc+d2BfiaEZabDfrMV81aeZQG/3o+V8h9imkrPc2MShK0OI4DcgiPzkhGI2iFHnrZ4UajXblwRDEReqSa1fGEvUHOegMuBgd16YuhJA7+Fq1P9zJySwPS5fNzzFDQlegLc= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=cnYZv9ki DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 609374BB8F60 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1781518484; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7I30Btj2Qe0GP53oPi1fEpPKggqtc9ifBCsyAss3h6w=; b=cnYZv9kiNtBELUNY0ql/6Mx/+d0vPrtMnuJ9vtplSAVnZmURNkIepR2sAOvlevd4STGYUt YkjWYtY798rZMVo/NmnrUlkxmwqIs9hjhiOURLmtlUHq/IAWd2v6cormtPUC6BCEPTuebk vrfARM8K0arFgRiEu/AYrbySl0GeGvI= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-42-QlXO3OzfMWioO-NhRIIjvw-1; Mon, 15 Jun 2026 06:14:41 -0400 X-MC-Unique: QlXO3OzfMWioO-NhRIIjvw-1 X-Mimecast-MFC-AGG-ID: QlXO3OzfMWioO-NhRIIjvw_1781518481 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-46067399d5dso1414505f8f.2 for ; Mon, 15 Jun 2026 03:14:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781518480; x=1782123280; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7I30Btj2Qe0GP53oPi1fEpPKggqtc9ifBCsyAss3h6w=; b=YIhG4fP9brfDzSoE0Xm2zwZ9Eca05kxDToCI7RoFBfpU7Qc3P/tJPsJr+T3T4X9UdU qAQqhF1QCRDk2RIz1O8ub7YnwdQcDLy4gmG1NZkCIs78pXr9xQgGmrn/melEbdfCwno7 av6XeR+PyndaXxHvST7ScS0c9unl+EOE49AsDWf82QubGg+iUy8itG53Mjy5jRAex092 AWm2UyoozkxZSxHb/qaAD1p3rjKawMAGXjfTSf3Wn5q+J25tiPEtVZ2z7wYDqGKSh4nt +FqIjcu5Vtm7yABGpZI72b/7VkB4uXYOnFvt8mud8A5NznVof1IoRxwPm1R627/fXyoj UpRg== X-Gm-Message-State: AOJu0Yzdd9O7iGRKGNRjAGkzLGxoXZWp1n3wITjtgg1uceuoyOtD8scm E/zXbHWyPtij0XZjdtRAM3AayGq2RE0TsS9KpKPx/rKRxDc1myPdoQjpOFenbDXponMZ5yNI6u5 FSq3CYyY66zOe1LWq0VoH0Y+wtoPg4fF1Uu3plUQ2RxsduKnoJ0Bw1ovTN243MnZHxTAG+5s= X-Gm-Gg: Acq92OHrC6M56t6NYzqpWnM/He2RmjZYxb2HbQPnEmjaEIDez2mJMg+ioIJIHyDjrTu EtgNz41fvYVStFXWow8t4fCAQMgkmy/y+BFSKkX5ZHa5+bpcWfcVChLl8fiKgGHqKM9puBe756R 3bOWNYfoUaLrJWWVHQje4sG3Iz/oAcxqJObnPXeJgu4P/PP2AWwbyw1la8iC2mfvVMirvicCbQ0 f1XsP1XKw09LKUoiVsOCvRbzPJGCNmuB8WBzhjl44kWZ4c3Ta8zBG64nAHxJBtP/D/AC1rmUbrx 5H1XX0fqTxQPRqLLolMx1j9qwCmHRjKyAYaemTYAsxQpAXKc/dRY65khVGoUJWer0HZ4T5YvafT AM+Jm0N7HpI5ngNXK3VyGMD0Mfej7iS39BnBSRodi X-Received: by 2002:a05:6000:607:b0:460:6b68:edb3 with SMTP id ffacd0b85a97d-4606dba3c50mr19541140f8f.32.1781518480303; Mon, 15 Jun 2026 03:14:40 -0700 (PDT) X-Received: by 2002:a05:6000:607:b0:460:6b68:edb3 with SMTP id ffacd0b85a97d-4606dba3c50mr19541072f8f.32.1781518479615; Mon, 15 Jun 2026 03:14:39 -0700 (PDT) Received: from localhost (19.81.93.209.dyn.plus.net. [209.93.81.19]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4606f2c5266sm37789966f8f.29.2026.06.15.03.14.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jun 2026 03:14:39 -0700 (PDT) From: Andrew Burgess To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: [PATCHv2 2/3] gdb: introduce program_space::get_entry_point_info function In-Reply-To: <86ecicnvfk.fsf@gnu.org> References: <41fe591d58ba010fa771e80ca674b61e30feef2f.1780942441.git.aburgess@redhat.com> <864cefb52d208dd8aac6b1b5f452cadad7546af8.1781214731.git.aburgess@redhat.com> <86ecicnvfk.fsf@gnu.org> Date: Mon, 15 Jun 2026 11:14:38 +0100 Message-ID: <87ik7kp0tt.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Nu79HA-vG_0rczS6xTrLXYqEbM7b0AXa-9QQ6Uih2dg_1781518481 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 Eli Zaretskii writes: >> 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 I rewrote the doc/ part to try and make it more approachable. I included some text describing how the reported addresses relate to the address of 'main', and why the inferior entry address exists, and is different for dynamically linked executables. Obviously the text relating to dynamically linked executables is a massive simplification, but I don't see it as our job to be teaching about dynamic linking, I figure what I've written is correct enough. If I don't hear any feedback I'll assume this is OK. Thanks, Andrew --- diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index a698b2b8451..4c0c4709a23 100644 --- a/gdb/doc/gdb.texinfo +++ b/gdb/doc/gdb.texinfo @@ -43212,6 +43212,28 @@ 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 inferior entry address and the executable +entry address. + +Neither address is the address of @code{main}. When a program is +started, low-level startup code (typically a function called +@code{_start}) runs before @code{main} is called. + +The executable entry address is the address of this startup code +within the main executable (@pxref{Files, ,Commands to Specify +Files}). + +The inferior entry address is the address of the very first +instruction executed when the inferior is started. For statically +linked programs this is the same as the executable entry address. For +dynamically linked programs the run-time linker must execute first in +order to load shared libraries, so the inferior entry address will be +an address within the run-time linker rather than within the main +executable. @end table The following command is useful for non-interactive invocations of