Re: Fix for PR 1971 .

[Jim Blandy <jimb@red-bean.com>]

On 1/3/06, Jim Blandy <jimb@red-bean.com> wrote:
> On 1/3/06, Ramana Radhakrishnan <ramana.radhakrishnan@codito.com> wrote:
> > Attached is a fix for PR 1971. This inserts a breakpoint at the return
> > address for a function that does not have a previous frame which is what
> > you have in the case of main. This would however not stop after the
> > return from main because the semantics of the next command would not
> > stop the execution in any place where there is no debug information.
> >
> > Tested on native x86 with today's head as well as 6.4 branch with no
> > extra regressions .
>
> Is this the behavior we actually want?  Where the user hasn't "set
> backtrace past-main on", isn't it the correct behavior for GDB to
> allow the program to exit when doing a 'next' out of main?  (I assume
> that, if one does a 'set backtrace past-main on', then 'next' works as
> you suggest it should.)

Oh, wait.  I might understand better now.  The current behavior is a
segfault, as get_prev_frame returns NULL.  The code you patched is
clearly wrong as it stands, since it doesn't account for that
possibility.  The behavior with your patch is that 'next' from main
causes the program to run to completion when past-main is off, as I
suggested it ought.  Right?

I see three uses of insert_step_resume_breakpoint_at_frame
(get_prev_frame (get_current_frame ())) in infrun.c; would it be
reasonable to add a new function in the
insert_step_resume_breakpoint_at_* family,
insert_step_resume_breakpoint_at_caller (say), that sets the
step-resume breakpoint at a sal built from the given frame's return
address?

I think you'd want to use frame_pc_unwind in that function, and not
gdbarch_unwind_pc.