This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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 14:57:16 -0500

 Andrew Cagney <ac131313 at redhat dot com> writes:
 
 > > 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().
 
 Are you sure?
 
 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]