public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* Frame context problem
@ 2003-07-03 20:36 Nick Kelsey
  0 siblings, 0 replies; 2+ messages in thread
From: Nick Kelsey @ 2003-07-03 20:36 UTC (permalink / raw)
  To: gdb

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Frame context problem
@ 2003-07-04  3:50 Jafa
  0 siblings, 0 replies; 2+ messages in thread
From: Jafa @ 2003-07-04  3:50 UTC (permalink / raw)
  To: gdb

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-07-04  3:50 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-03 20:36 Frame context problem Nick Kelsey
2003-07-04  3:50 Jafa

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).