Re: ignore helper no longer works?

["Jafa" <jafa at silicondust dot com>]

Ok, the solution is obvious now that I am looking at it a different way...

When in an epilogue stub search for the return address on the stack, even
though the prologue code has indicated that the stub itself did not save the
return address. It doesn't matter who called the epilogue stub, just the
fact that they did means that they saved the return address in their own
prologue.

The only issue is that the stack backtrace will show the current function
being the epilogue stub and its caller being the real functions caller.

Thanks Andrew for your advice - it got me thinking along the right lines.

Nick

----- Original Message -----
From: "Jafa" <jafa@silicondust.com>
To: "Andrew Cagney" <ac131313@redhat.com>
Cc: <gdb@sources.redhat.com>
Sent: Thursday, July 03, 2003 10:25 AM
Subject: Re: ignore helper no longer works?


Hi Andrew,

>- When stepping, the need to identify and single step through
>trampolines / helpers.

I have updated the backtrace code so that if it detects that it is in an
epilogue stub then return a frame with no known return address (0) and no
known FP (0).

I can probably work out the FP of the previous function if need be, but have
no hope (without some simulation) of figuring out the return address.

Step-over at the end of a fucntion results in gdb running without stopping
(and it doesn't call ignore_helper).

One way to address this problem would be for gdb to call ignore_helper, and
then know not attempt a stack-backtrace.

Another solution (ok, crude hack) would be for the tdep to cache the last
known PC so that if it steps into a stub then it knows where it came from.

>- When stopped, the need to back trace out of a trampoline / helper.

I think it is accceptable not being able to do a backtrace if you are in an
epilogue helper.... the code now returns that the FP and PC are unknown to
abort the backtrace.

I am open to ideas (I figure this must be a rare but general problem). If
all else fails I will implement the crude hack above because I need to get
this working.

Thanks

Nick

----- Original Message -----
From: "Andrew Cagney" <ac131313@redhat.com>
To: "Jafa" <jafa@silicondust.com>
Cc: <gdb@sources.redhat.com>
Sent: Thursday, July 03, 2003 8:10 AM
Subject: Re: ignore helper no longer works?



> 1) Say it is my responsibility to determine the return address anywhere in
> code, even if it means writing a whole lot of code in gdb to simulate the
> execution of these stubs.
>
> 2) Fix gdb at a higher level so that it doesn't try to obtain a return
> address from a helper function - instead keep stepping (like it gdb used
to
> do).

Sounds like you've got two problems:

- When stepping, the need to identify and single step through
trampolines / helpers.

- When stopped, the need to back trace out of a trampoline / helper.

Given a core file, it isn't possible to `step'.  Your unwinder is going
to need to identify and dig itself out of that hole.  Main thing to do
is to not lie - from what I understand of your case, given a callee that
jumped to a helper, you'll end up displaying:
<helper>
caller

Andrew


> I can figure out the FP ok (all be it that it is painful without being
able
> to see the prologue) - the old system only asked for the FP and after
> detecting that it was the same frame, kept stepping.
>
> BTW - I have also noticed that gdb now does not call ignore_helper for any
> step-over operations, instead relying on the tdep to supply the return
> address for the stub. It think it always used to call ignore_helper and if
> it was a helper then it stepped rather that setting a breakpoint as if it
> was a function.
>
> I don't want to be too quick to butcher infrun - I would appreciate your
> advice.