This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: tdep/1155: s/390 Linux: GDB can't reselect the right frame after an inferior function call
- From: Jim Blandy <jimb at redhat dot com>
- To: cagney at redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 28 Mar 2003 17:38:00 -0000
- Subject: Re: tdep/1155: s/390 Linux: GDB can't reselect the right frame after an inferior function call
- Reply-to: 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
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?