Re: exp/1155: s/390 Linux: GDB can't reselect the right frame after an inferior function call

[Jim Blandy <jimb at redhat dot com>]

The following reply was made to PR tdep/1155; it has been noted by GNATS.

From: Jim Blandy <jimb at redhat dot com>
To: Andrew Cagney <ac131313 at redhat dot com>
Cc: gdb-gnats at sources dot redhat dot com, Elena Zannoni <ezannoni at redhat dot com>
Subject: Re: exp/1155: s/390 Linux: GDB can't reselect the right frame after an inferior function call
Date: 27 Mar 2003 16:18:36 -0500

 Andrew Cagney <ac131313 at redhat dot com> writes:
 
 > > No.
 > >> The problem is that the legacy dummy frame code matches either SP or
 > >> FP when trying to re-locate a saved frame.  It should instead match
 > >> just a single frame ID.
 > >> Please see save_dummy_frame_tos() and unwind_dummy_id().
 > > Are you sure?
 > 
 > Yes.
 > 
 > > I see that save_inferior_status saves the ID of main's frame in
 > > inf_status->selected_frame_id, and then restore_inferior_status passes
 > > that ID through to restore_selected_frame, which then calls
 > > frame_find_by_id, and returns marker1's frame.
 > > The dummy frame is properly popped, and is long gone before any of
 > > this happens.  Neither of the two methods you mentioned are involved
 > > at all.
 > 
 > Perhaphs that is the problem?
 
 No --- the call paths involved don't invoke any gdbarch methods that I
 could redefine.
 
 hand_function_call
   -> save_inferior_status
      -> get_frame_id, which is stored in the 'struct inferior_status'.
 
 Then, after the call returns neatly:
 
 hand_function_call
   -> do_restore_inferior_status_cleanup (via do_cleanups)
      -> restore_inferior_status
         -> restore_selected_frame (via catch_errors)
            -> frame_find_by_id
               -> get_frame_id
               -> frame_id_eq
 
 Everything that happens here is outside the control of gdbarch
 methods, it seems to me.