Re: [PATCHv3 2/4] gdb: introduce program_space::get_entry_point_info function

[Eli Zaretskii <eliz@gnu.org>]

> From: Andrew Burgess <aburgess@redhat.com>
> Cc: Guinevere Larsen <guinevere@redhat.com>,
> 	Pedro Alves <pedro@palves.net>,
> 	Andrew Burgess <aburgess@redhat.com>,
> 	Eli Zaretskii <eliz@gnu.org>
> 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 <eliz@gnu.org>
> ---
>  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 <eliz@gnu.org>