public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: "Jafa" <jafa@silicondust.com>
To: <gdb@sources.redhat.com>
Subject: Re: Frame context problem
Date: Fri, 04 Jul 2003 03:50:00 -0000	[thread overview]
Message-ID: <017601c341df$221aa5b0$0a02a8c0@scenix.com> (raw)

Ok, now I have this problem identified properly...

ip2k port, you are at the end of a function and you do a step or a next...

GDB steps few times and the code does a jump to an epilogue handler.

At this point GDB inserts a breakpoint to skip what it thinks is a
subroutine and specifies the current function as the context to accept the
breakpoint.

Obviously this will not work because the stub will not return to the
function, it will return to its parent.

BTW - This would seam to be the same problem as when gcc optimizes a call
followed by a ret to a jump.

Ideas:

1) Trick gdb into thinking that the epilogue stub is part of the same
function rather than being a subroutine. This would address this problem but
will not address the issue of the above-mentioned gcc optimization (not
relavant to the ip2k anyway).

2) Add two step-resume breakpoints, one refering to the current context, and
one refering to its parent.

3) Allow the step-resume breakpoint to accept either of two contexts... the
current or its parent.

If gcc for other ports does the call_ret -> jump optimization then I would
expect this to be a common problem?

Nick

>Hi guys,
>
>So close... so close :-)
>
>Situation: At the end of a function, click step-over or step-into...
>
>- single steps until it reaches the epilogue stub.
>- asks for the frame, I return the FP as it was for the function, and the
PC
>return address to get back to the caller.
>- gdb inserts a breakpoint at the return address I specified.
>- gdb runs and stops at the breakpoint correctly.
>- gdb removes the breakpoint, single steps, re-inserts the breakpoint and
>continues!!!
>
>So it must think that the context is wrong... can you please point me in
the
>right direction? Where is the decision made regarding deciding if this was
>were it was ment to stop?
>
>Thnaks
>
>Nick


             reply	other threads:[~2003-07-04  3:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-04  3:50 Jafa [this message]
2003-07-04  7:16 ` canned functions jacques
  -- strict thread matches above, loose matches on Subject: below --
2003-07-03 20:36 Frame context problem Nick Kelsey

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='017601c341df$221aa5b0$0a02a8c0@scenix.com' \
    --to=jafa@silicondust.com \
    --cc=gdb@sources.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).