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: tdep/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
Subject: Re: tdep/1155: s/390 Linux: GDB can't reselect the right frame after an inferior function call
Date: 28 Mar 2003 12:31:53 -0500

 Andrew Cagney <ac131313 at redhat dot com> writes:
 > > Andrew Cagney <ac131313 at redhat dot com> writes:
 > >
 > >> 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?
 > > Yes --- the ID base does point at the outermost address on the S/390.
 > > I was thinking about switching it to the innermost address, which
 > > would distinguish the frames in this case, but that was going to take
 > > some time for me to figure out, so thought I should report the bug in
 > > some form until that was resolved.
 > 
 > This explains why, of all the architectures, only the s390 is seeing
 > this problem.  That stack address needs to be constant throughout the
 > lifetime of the frame, and the easiest safest way of doing that is to
 > put it at the start of the frame.
 
 Well, what I said isn't quite right.  Frames for functions that don't
 call alloca use the SP as their ID.  Functions that do call alloca
 allocate a frame pointer register, and we use that as the ID for those
 frames.  So either way the ID is constant throughout the life of the
 frame; but it isn't always the outermost end of the stack.
 
 That said, it seems reasonable to switch.
 
 > > The comments in frame_id_eq indicate that it's supposed to be
 > > comparing the pc's, too, but the code just hasn't been written yet.
 > > If that code were written, then this problem would go away:
 > > frame_find_by_id is already written to check all the frames that
 > > aren't too far in, so it'll check all frames with identical bases for
 > > one whose function matches.  That is the solution I was hoping to see.
 > 
 > That is orthogonal.  Changing that, without also fixing the s390, will
 > leave GDB open to botching edge cases.
 
 Because (I had incorrectly suggested) it changes, right?  Or for other
 reasons?


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