Re: [PATCHv9 3/4] gdb: allow 'until' to work in outermost frame

[Simon Marchi <simark@simark.ca>]

On 8/24/26 12:22 PM, Andrew Burgess wrote:
> The 'until' command with an argument, e.g. 'until *ADDRESS', is
> implemented by until_break_command in breakpoint.c.
> 
> The most important thing this function does is convert the location
> argument, '*ADDRESS' in my example, into a vector of symtab_and_line
> objects.  Each of these symtab_and_line objects is then used to create
> a temporary bp_until breakpoint.
> 
> The other thing that until_break_command does is create a breakpoint
> in the caller frame.  This breakpoint is there to ensure the inferior
> stops upon exiting the frame in which the 'until' command was issued,
> if the until breakpoint was not hit.
> 
> When compiling an assembler file into a static test program, if I use
> 'starti' to stop the inferior within the outermost frame, and then try
> to use 'until *ADDRESS' I see the following error:
> 
>   (gdb) starti
>   Starting program: /tmp/hello
> 
>   Program stopped.
>   0x0000000000401000 in _start ()
>   (gdb) bt
>   #0  0x0000000000401000 in _start ()
>   (gdb) until *0x0000000000401015
>   Warning:
>   Cannot insert breakpoint 0.
>   Cannot access memory at address 0x1
> 
>   Command aborted.
>   (gdb)
> 
> The problem here is the breakpoint that 'until' tries to create in the
> caller frame.  Though the 'bt' in the above example indicates that
> there is only a single frame, the outermost frame, this is only
> because GDB has specific code in get_prev_frame to stop the backtrace
> at the outermost frame.  If we turn this off and try 'bt' again:
> 
>   (gdb) set backtrace past-entry on
>   (gdb) bt
>   #0  0x0000000000401000 in _start ()
>   #1  0x0000000000000001 in ?? ()
>   #2  0x00007fffffffac73 in ?? ()
>   #3  0x0000000000000000 in ?? ()
>   (gdb)
> 
> What we are seeing here is the garbage values that happen to be in the
> registers tricking GDB into thinking there are frames before _start.
> 
> GDB's code to handle this is in get_prev_frame, where we call
> inside_entry_func.  This checks if a frame is one of the two possible
> entry frames, the inferior entry frame or the executable entry frame.
> See the previous commit for more details.  The important thing is that
> the inferior entry frame is the absolute outer frame, the very first
> frame that the inferior executed when starting, while the executable
> entry frame is just the first frame within the main executable.
> 
> There are a number of user configurable filters in get_prev_frame, the
> backtrace past-main filter, the backtrace frame limit filter, and the
> backtrace past-entry filter that we are discussing here.
> 
> When creating the caller frame breakpoint, the 'until' command doesn't
> use get_prev_frame, it uses frame_unwind_caller_frame, which calls
> get_prev_frame_always.  This is so that the user configurable filters
> don't prevent the caller frame breakpoint from being created.  But
> this means that when creating the breakpoint, we skip the entry frame
> check.  As a result, the 'until' command will try to place a
> breakpoint in the bogus frame #1 shown above.  As the frame is at
> address 0x1, which is non-writable, we see an error when trying to
> insert the breakpoint.
> 
> In this commit I propose that we add an entry frame check into
> frame_unwind_caller_frame path, similar to the one found in
> get_prev_frame.
> 
> To achieve this I create get_prev_frame_with_entry_frame_check, a new
> function that checks if a frame is an entry frame, and returns NULL if
> it is.  Otherwise, get_prev_frame_with_entry_frame_check just calls
> get_prev_frame_always.
> 
> Then in get_prev_frame and frame_unwind_caller_frame, instead of
> calling get_prev_frame_always directly, we can call the new
> get_prev_frame_with_entry_frame_check.
> 
> Finally, the existing entry frame check can be removed from
> get_prev_frame.
> 
> Notice that in moving the entry frame check from get_prev_frame I have
> removed the 'frame_pc.has_value ()' check.  Previously
> inside_entry_func called get_frame_func which would throw if the
> frame's $pc was not available.  I have updated inside_entry_func to
> call get_frame_func_if_available, which doesn't throw.  As a result
> the `frame_pc.has_value ()` check is no longer needed.
> 
> An earlier version of this patch tried moving the inside_entry_frame
> check into get_prev_frame_always, however, if get_prev_frame_always is
> unable to unwind a frame then it must set the stop reason on the last
> frame, this can be seen in `get_frame_unwind_stop_reason` where the
> assert `gdb_assert (frame->prev_p);` will trigger if the previous
> frame is not setup correctly.
> 
> Setting the stop reason means the decision about whether there's a
> previous frame or not is permanent (at least until the next frame
> cache flush), but we need commands like 'bt -past-entry' to work,
> which means the choice for whether there's a previous frame or not
> needs to remain dynamic.
> 
> The test for this fix ran into an issue where the frame-id for the
> outermost frame would change between the first instruction and later
> instructions in the frame.  This was true for both the executable
> entry frame and the inferior entry frame.  I created bug PR gdb/34245
> for this issue.
> 
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34245

You could also add:

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34211

Simon