From: Andrew Burgess <aburgess@redhat.com>
To: gdb-patches@sourceware.org
Cc: Andrew Burgess <aburgess@redhat.com>, Pedro Alves <pedro@palves.net>
Subject: [PATCHv4 1/4] gdb: rename program_space::entry_point_address* functions
Date: Tue, 23 Jun 2026 11:47:13 +0100 [thread overview]
Message-ID: <cf1a8c8fb29c4883635cd027dfe10f2119533d0b.1782211508.git.aburgess@redhat.com> (raw)
In-Reply-To: <cover.1782211508.git.aburgess@redhat.com>
Rename program_space::entry_point_address to
program_space::exec_entry_point_address and
program_space::entry_point_address_query to
program_space::exec_entry_point_address_if_available.
There are two aspects to this renaming. First I replace 'query' with
'if_available' in one of the functions. I feel this better describes
the function, and also is inline with how other, similar, functions
are named in GDB.
The second part of the renaming is to add the 'exec_' prefix to the
front of both function names. When a dynamically linked inferior is
started the first instruction executed is actually within the
run-time linker, not within the main executable, so it could be
argued that the actual entry address for the inferior is not the entry
address of the main executable.
However, there is an equally valid argument that the entry address of
the executable is also something worth finding. The existing entry
address within the inferior is used for a number of tasks in GDB, for
example displaced stepping (arch-utils.c), inferior function
calls (arc-tdep.c and infcall.c), and for detecting the "entry" frame.
This last one, the entry frame detection is interesting. In a
dynamically linked executable it could be argued that there are two
entry frames. The very first frame that is executed in the inferior,
this is where 'starti' stops the inferior. And then the very first
frame within the main executable. I think that both of these are
valid.
Currently, as we can only find the entry address within the main
executable, we can only identify the first frame of the main
executable. And this can cause some problems, consider:
(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)
Here frames #1 to #3 are all bogus, created by GDB based on whatever
values happen to be in the registers when the inferior starts.
In a later commit I'd like to fix this problem, however, I would
prefer that the other users of program_space::entry_point_address
continue to use the address within the main executable.
So, in order to keep the distinction between the two different types
of entry point, I'm renaming the existing functions with the 'exec_'
prefix.
There should be no user visible changes after this commit.
Approved-By: Pedro Alves <pedro@palves.net>
---
gdb/arc-tdep.c | 2 +-
gdb/arch-utils.c | 2 +-
gdb/frame.c | 4 ++--
gdb/infcall.c | 2 +-
gdb/linux-tdep.c | 2 +-
gdb/progspace.c | 6 +++---
gdb/progspace.h | 12 ++++++------
gdb/solib-frv.c | 2 +-
8 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/gdb/arc-tdep.c b/gdb/arc-tdep.c
index 4936a5c8fbb..7ed83c4cae6 100644
--- a/gdb/arc-tdep.c
+++ b/gdb/arc-tdep.c
@@ -860,7 +860,7 @@ arc_push_dummy_code (struct gdbarch *gdbarch, CORE_ADDR sp, CORE_ADDR funaddr,
struct regcache *regcache)
{
*real_pc = funaddr;
- *bp_addr = current_program_space->entry_point_address ();
+ *bp_addr = current_program_space->exec_entry_point_address ();
return sp;
}
diff --git a/gdb/arch-utils.c b/gdb/arch-utils.c
index e959788bd3b..88047731ce6 100644
--- a/gdb/arch-utils.c
+++ b/gdb/arch-utils.c
@@ -57,7 +57,7 @@ displaced_step_at_entry_point (struct gdbarch *gdbarch)
CORE_ADDR addr;
int bp_len;
- addr = current_program_space->entry_point_address ();
+ addr = current_program_space->exec_entry_point_address ();
/* Inferior calls also use the entry point as a breakpoint location.
We don't want displaced stepping to interfere with those
diff --git a/gdb/frame.c b/gdb/frame.c
index f64f5554f8c..f5a6a8919df 100644
--- a/gdb/frame.c
+++ b/gdb/frame.c
@@ -2700,7 +2700,7 @@ static bool
inside_entry_func (const frame_info_ptr &this_frame)
{
std::optional<CORE_ADDR> entry_point
- = current_program_space->entry_point_address_query ();
+ = current_program_space->exec_entry_point_address_if_available ();
if (!entry_point.has_value ())
return false;
@@ -2776,7 +2776,7 @@ get_prev_frame (const frame_info_ptr &this_frame)
added to work around that (now fixed) case. */
/* NOTE: cagney/2003-07-15: danielj (if I'm reading it right)
suggested having the inside_entry_func test use the
- inside_main_func() msymbol trick (along with entry_point_address()
+ inside_main_func() msymbol trick (along with exec_entry_point_address()
I guess) to determine the address range of the start function.
That should provide a far better stopper than the current
heuristics. */
diff --git a/gdb/infcall.c b/gdb/infcall.c
index e6b24ff5310..6d26841ede3 100644
--- a/gdb/infcall.c
+++ b/gdb/infcall.c
@@ -1300,7 +1300,7 @@ call_function_by_hand_dummy (struct value *function,
CORE_ADDR dummy_addr;
real_pc = funaddr;
- dummy_addr = current_program_space->entry_point_address ();
+ dummy_addr = current_program_space->exec_entry_point_address ();
/* A call dummy always consists of just a single breakpoint, so
its address is the same as the address of the dummy.
diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c
index a7381677498..d03e4768792 100644
--- a/gdb/linux-tdep.c
+++ b/gdb/linux-tdep.c
@@ -2952,7 +2952,7 @@ linux_displaced_step_location (struct gdbarch *gdbarch)
/* Determine entry point from target auxiliary vector. This avoids
the need for symbols. Also, when debugging a stand-alone SPU
- executable, entry_point_address () will point to an SPU
+ executable, exec_entry_point_address () will point to an SPU
local-store address and is thus not usable as displaced stepping
location. The auxiliary vector gets us the PowerPC-side entry
point address instead. */
diff --git a/gdb/progspace.c b/gdb/progspace.c
index 1407b058dfd..0e8516f4640 100644
--- a/gdb/progspace.c
+++ b/gdb/progspace.c
@@ -263,7 +263,7 @@ program_space::empty ()
/* See progspace.h. */
std::optional<CORE_ADDR>
-program_space::entry_point_address_query () const
+program_space::exec_entry_point_address_if_available () const
{
objfile *objf = symfile_object_file;
if (objf == NULL || !objf->per_bfd->ei.entry_point_p)
@@ -276,9 +276,9 @@ program_space::entry_point_address_query () const
/* See progspace.h. */
CORE_ADDR
-program_space::entry_point_address () const
+program_space::exec_entry_point_address () const
{
- std::optional<CORE_ADDR> retval = entry_point_address_query ();
+ std::optional<CORE_ADDR> retval = exec_entry_point_address_if_available ();
if (!retval.has_value ())
error (_("Entry point address is not known."));
diff --git a/gdb/progspace.h b/gdb/progspace.h
index e9261ff8590..1ae1e42f3bb 100644
--- a/gdb/progspace.h
+++ b/gdb/progspace.h
@@ -323,13 +323,13 @@ struct program_space
return m_target_sections;
}
- /* If there is a valid and known entry point in this program space,
- return it. Otherwise return an empty optional. */
- std::optional<CORE_ADDR> entry_point_address_query () const;
+ /* If there is a valid and known entry point in the main executable of
+ this program space, return it. Otherwise return an empty optional. */
+ std::optional<CORE_ADDR> exec_entry_point_address_if_available () const;
- /* Get the entry point address in this program space. Call error if
- it is not known. */
- CORE_ADDR entry_point_address () const;
+ /* Get the entry point address for the main executable in this program
+ space. Call error if it is not known. */
+ CORE_ADDR exec_entry_point_address () const;
/* Return true if any objfile of this program space has partial
symbols. */
diff --git a/gdb/solib-frv.c b/gdb/solib-frv.c
index 4f0aac31e73..69b882e534a 100644
--- a/gdb/solib-frv.c
+++ b/gdb/solib-frv.c
@@ -689,7 +689,7 @@ enable_break (void)
}
std::optional<CORE_ADDR> entry_point
- = current_program_space->entry_point_address_query ();
+ = current_program_space->exec_entry_point_address_if_available ();
if (!entry_point.has_value ())
{
solib_debug_printf ("Symbol file has no entry point.");
--
2.25.4
next prev parent reply other threads:[~2026-06-23 10:47 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 18:14 [PATCH] gdb: allow 'until' to work in outermost frame Andrew Burgess
2026-06-11 19:24 ` Guinevere Larsen
2026-06-11 20:40 ` Andrew Burgess
2026-06-12 12:49 ` Guinevere Larsen
2026-06-11 21:59 ` [PATCHv2 0/3] " Andrew Burgess
2026-06-11 21:59 ` [PATCHv2 1/3] gdb: rename program_space::entry_point_address* functions Andrew Burgess
2026-06-12 15:41 ` Pedro Alves
2026-06-11 21:59 ` [PATCHv2 2/3] gdb: introduce program_space::get_entry_point_info function Andrew Burgess
2026-06-12 6:07 ` Eli Zaretskii
2026-06-15 10:14 ` Andrew Burgess
2026-06-15 12:01 ` Eli Zaretskii
2026-06-12 15:41 ` Pedro Alves
2026-06-15 10:29 ` Andrew Burgess
2026-06-16 18:36 ` Pedro Alves
2026-06-23 9:46 ` Andrew Burgess
2026-06-23 10:20 ` Pedro Alves
2026-06-11 21:59 ` [PATCHv2 3/3] gdb: allow 'until' to work in outermost frame Andrew Burgess
2026-06-12 15:57 ` Pedro Alves
2026-06-16 19:47 ` [PATCHv3 0/4] " Andrew Burgess
2026-06-16 19:47 ` [PATCHv3 1/4] gdb: rename program_space::entry_point_address* functions Andrew Burgess
2026-06-16 19:47 ` [PATCHv3 2/4] gdb: introduce program_space::get_entry_point_info function Andrew Burgess
2026-06-17 11:52 ` Eli Zaretskii
2026-06-16 19:47 ` [PATCHv3 3/4] gdb: allow 'until' to work in outermost frame Andrew Burgess
2026-06-16 19:47 ` [PATCHv3 4/4] gdb: cache program space entry point information Andrew Burgess
2026-06-23 10:47 ` [PATCHv4 0/4] gdb: allow 'until' to work in outermost frame Andrew Burgess
2026-06-23 10:47 ` Andrew Burgess [this message]
2026-06-23 10:47 ` [PATCHv4 2/4] gdb: introduce program_space::get_entry_point_info function Andrew Burgess
2026-06-23 10:47 ` [PATCHv4 3/4] gdb: allow 'until' to work in outermost frame Andrew Burgess
2026-06-23 10:47 ` [PATCHv4 4/4] gdb: cache program space entry point information Andrew Burgess
2026-06-25 15:26 ` [PATCHv5 0/4] gdb: allow 'until' to work in outermost frame Andrew Burgess
2026-06-25 15:26 ` [PATCHv5 1/4] gdb: rename program_space::entry_point_address* functions Andrew Burgess
2026-06-25 15:26 ` [PATCHv5 2/4] gdb: introduce program_space::get_entry_point_info function Andrew Burgess
2026-06-25 15:26 ` [PATCHv5 3/4] gdb: allow 'until' to work in outermost frame Andrew Burgess
2026-06-25 15:26 ` [PATCHv5 4/4] gdb: cache program space entry point information Andrew Burgess
2026-07-10 14:24 ` [PATCHv6 0/4] gdb: allow 'until' to work in outermost frame Andrew Burgess
2026-07-10 14:24 ` [PATCHv6 1/4] gdb: rename program_space::entry_point_address* functions Andrew Burgess
2026-07-10 14:24 ` [PATCHv6 2/4] gdb: introduce program_space::get_entry_point_info function Andrew Burgess
2026-07-10 15:39 ` Simon Marchi
2026-07-10 14:24 ` [PATCHv6 3/4] gdb: allow 'until' to work in outermost frame Andrew Burgess
2026-07-10 17:00 ` Simon Marchi
2026-07-10 17:01 ` Simon Marchi
2026-07-16 15:06 ` Andrew Burgess
2026-07-10 14:24 ` [PATCHv6 4/4] gdb: cache program space entry point information Andrew Burgess
2026-07-10 17:07 ` Simon Marchi
2026-07-18 13:11 ` [PATCHv7 0/4] gdb: allow 'until' to work in outermost frame Andrew Burgess
2026-07-18 13:11 ` [PATCHv7 1/4] gdb: rename program_space::entry_point_address* functions Andrew Burgess
2026-07-18 13:11 ` [PATCHv7 2/4] gdb: introduce program_space::get_entry_point_info function Andrew Burgess
2026-07-18 13:11 ` [PATCHv7 3/4] gdb: allow 'until' to work in outermost frame Andrew Burgess
2026-07-18 13:11 ` [PATCHv7 4/4] gdb: cache program space entry point information Andrew Burgess
2026-07-20 9:52 ` [PATCHv8 0/4] gdb: allow 'until' to work in outermost frame Andrew Burgess
2026-07-20 9:52 ` [PATCHv8 1/4] gdb: rename program_space::entry_point_address* functions Andrew Burgess
2026-07-20 9:52 ` [PATCHv8 2/4] gdb: introduce program_space::get_entry_point_info function Andrew Burgess
2026-07-20 9:52 ` [PATCHv8 3/4] gdb: allow 'until' to work in outermost frame Andrew Burgess
2026-07-20 9:52 ` [PATCHv8 4/4] gdb: cache program space entry point information Andrew Burgess
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cf1a8c8fb29c4883635cd027dfe10f2119533d0b.1782211508.git.aburgess@redhat.com \
--to=aburgess@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=pedro@palves.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox