public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>, Jim Blandy <jimb@redhat.com>
Cc: gdb@sources.redhat.com
Subject: Re: [Fwd: Re: tdep/1155: s/390 Linux: GDB can't reselect the right frame after an inferior function call]
Date: Sun, 30 Mar 2003 16:57:00 -0000	[thread overview]
Message-ID: <3E872208.2050401@redhat.com> (raw)
In-Reply-To: <20030327213715.GA19131@nevyn.them.org>

> 
> The original bug, as filed, said:
> 
> <quote>
> If you ask GDB to make an inferior function call when the youngest
> frame is a frameless function, and the selected frame is the
> second-to-youngest frame, then GDB will not properly re-select the
> second-to-youngest frame when the inferior call returns.
> 
> 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.
> </quote>
> 
> In what way do you see this problem as resolved?

Just to close this, further analysis revealed that the s390's frame ID's 
stack address wasn't correct (wasn't constant, pointing at the wrong end 
of the frame).  Fixing that will fix the above.

It's also useful to note that, in the critical edge cases, GDB is 
already doing frame/func comparisons vis:
             case PRINT_UNKNOWN:
               /* FIXME: cagney/2002-12-01: Given that a frame ID does
                  (or should) carry around the function and does (or
                  should) use that when doing a frame comparison.  */
               if (stop_step
                   && frame_id_eq (step_frame_id,
                                   get_frame_id (get_current_frame ()))
                   && step_start_function == find_pc_function (stop_pc))
Moving the test to frame_id_eq() is something of a clean up.  It will 
also make it possible to flush out all those remaining edge cases though.

Andrew


      parent reply	other threads:[~2003-03-30 16:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-27 21:32 Andrew Cagney
2003-03-27 21:37 ` Daniel Jacobowitz
2003-03-27 22:23   ` Andrew Cagney
2003-03-30 16:57   ` Andrew Cagney [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E872208.2050401@redhat.com \
    --to=ac131313@redhat.com \
    --cc=drow@mvista.com \
    --cc=gdb@sources.redhat.com \
    --cc=jimb@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).