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 afteran inferior function call
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: cagney at redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 28 Mar 2003 16:38:01 -0000
- Subject: Re: tdep/1155: s/390 Linux: GDB can't reselect the right frame afteran inferior function call
- Reply-to: 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: Jim Blandy <jimb 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: Fri, 28 Mar 2003 11:32:40 -0500
> 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.
> 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.
Andrew