Re: exp/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 exp/1155; it has been noted by GNATS.

From: Andrew Cagney <ac131313 at redhat dot com>
To: jimb at redhat dot com
Cc: gdb-gnats at sources dot redhat dot com
Subject: Re: exp/1155: s/390 Linux: GDB can't reselect the right frame after
 an inferior function call
Date: Thu, 27 Mar 2003 12:37:43 -0500

 > On the S/390, if a function doesn't use alloca, then the compiler just uses the stack pointer as the frame pointer.  This means that GDB's frame_info structures use the address of the low end of the frame as the frame base, not the high end.  (The S/390 stack grows downwards.)  So, if the youngest function call hasn't allocated any stack space, then its frame base address is equal to that of its caller.  This means that frame_find_by_id is unable to distinguish between the two.
 > 
 > There are comments in various versions of the code that suggest that Andrew (who has been doing lots of frame hacking recently) knows about this; as of 2003-11-29, frame_find_by_id said:
 > 
 >       /* FIXME: cagney/2002-04-21: This isn't sufficient.  It should
 > 	 use id.pc / this.pc to check that the two frames belong to
 > 	 the same function.  Otherwise we'll do things like match
 > 	 dummy frames or mis-match frameless functions.  However,
 > 	 until someone notices, stick with the existing behavour.  */
 > 
 > Okay --- somebody has noticed!  :)
 > 
 > As of 2003-3-27, that comment was gone, but frame_id_eq says:
 > 
 >   /* Add a test to check that the frame ID's are for the same function
 >      here.  */
 >   return 1;
 
 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().
 
 Andrew