Re: [RFA] OSF/1 - "next" over prologueless function call

[Joel Brobecker <brobecker@gnat.com>]

Sorry for the delay in my answers. I am traveling again now, and
will be on and off until next week.

> There's always plan B.
> 
> Looking at the body of that IF, I believe it always returns.  That 
> should let us do:
> 
> if (legacy_frame_p ())
>   if (all the existing tests)
>     call a function to do the body of work ()
>     return;
> else if (our new improved test)
>   call a function to do the body of work ()
>   return;
> 
> that way the legacy and non legacy cases are clearly split - we're free 
> to refine the new conditional with out worrying about breaking the old 
> code.  However ....


We might have to take that route, because I rechecked on Solaris, and I
forgot (yes, I forgot) to make the change there before I reran the test,
so of course there were no regressions. I feel very embarrassed.

> So I'm guessing for the moment just replace
> 	stop_pc == ecs->stop_func_start
> with the frame id test in the new code?

That works with x86-linux and alpha-tru64, but unfortunately breaks
on sparc-solaris. Maybe something minor, but the call-ar-st starts
timeouting and takes forever to complete after that change.

So I think we should follow your suggestion above and separate
completely the two conditions, conditionalized by legacy_frame_p().
The function name we could use, at least for now, could be
handle_subroutine_call() or handle_step_into_function().

It seems that the correct test when legacy_frame_p() is nonzero
would only be the frame ID equality test, but I must admit being
nervous again not knowing how reliable the new frame implementations
are... Despite the fact that the current heuristics (check if PC ==
address of function first instruction or is inside function prologue)
doesn't cover 100% of the cases, it was still a simple, platform
independent, solid test that worked in most cases. We are about to
replace that by something that's a bit more complex and might cause some
unexpected behavior if the unwinder fails to unwind properly (imagine
for instance that the unwinder skipped one frame).

I am really torn, so I am relying on you who has had a closer look at
the frame implementations that have been converted so far. If it was
just me, I would be very conservative and simply add and extra

  || (legacy_frame_p() && frame_id_eq (...))

It only fixes one problem, but the changes of introducing another is
smaller. I am a coward :-).

-- 
Joel