This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Frame context problem


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]