Re: tdep/1155: s/390 Linux: GDB can't reselect the right frame afteran inferior function call

[Andrew Cagney <ac131313 at redhat dot com>]

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

From: Andrew Cagney <ac131313 at redhat dot com>
To: gdb-gnats at sources dot redhat dot com, Jim Blandy <jimb at redhat dot com>
Cc:  
Subject: Re: tdep/1155: s/390 Linux: GDB can't reselect the right frame after
 an inferior function call
Date: Fri, 28 Mar 2003 09:19:35 -0500

 I still don't think this is the `dooms day senario' that those comments 
 elude to.  If it was, we'd have seen it long ago.
 
 Does your struct frame_id . base (a.k.a., stack_addr, nee frame->frame) 
 point at the outer most address of a stack frame?
 
 See dwarf2's cfi's definition of CFA, and this patch:
 http://sources.redhat.com/ml/gdb-patches/2003-03/msg00523.html
 +/* Return the frame base (what ever that is) (DEPRECATED).
 +
 +   Old code was trying to use this single method for two conflicting
 +   purposes.  Such code needs to be updated to use either of:
 +
 +   get_frame_id: A low level frame unique identifier, that consists of
 +   both a stack and a function address, that can be used to uniquely
 +   identify a frame.  This value is determined by the frame's
 +   low-level unwinder, the stack part [typically] being the
 +   top-of-stack of the previous frame, and the function part being the
 +   function's start address.  Since the correct identification of a
 +   frameless function requires both the a stack and function address,
 +   the old get_frame_base method was not sufficient.
 +
 +   get_frame_base_address: get_frame_locals_address:
 +   get_frame_args_address: A set of high-level debug-info dependant
 +   addresses that fall within the frame.  These addresses almost
 +   certainly will not match the stack address part of a frame ID (as
 +   returned by get_frame_base).  */
 
 Andrew