Re: [patch/rfc] Try to get dummy calls working on hpux again

[Randolph Chung <randolph@tausq.org>]

> Sigh (the relevant code will need comments explaining this).  Are you 
> absolutely positively certain this is true (for both HP/UX 10.20 / 
> 11.xx)? :-)

there is a comment that explains this already; is this not enough?
+      /* We set the breakpoint address and r31 to (close to) where the current
+         pc is; when __gcc_plt_call returns, it will restore pcsqh to the
+    current value based on this.  The -4 is needed for frame unwinding
+    to work properly -- we need to land in a different function than
+    the current function.  */

I've only tested on 11.11 so far.... do you mean "can we do something
simplier with another version of HPUX", or "will this also work with
another version of HPUX"? The answer to the latter is probably yes. The
original code that was deleted also did something similar, but in a much
more ugly way in some cases.

> Also that sequence in the call path, the return path, or both?

both; but it is done inside of __gcc_plt_call.

> Having the dummy-code containing a non-trivial sequence of instructions 
> opens up the problem of needing to be able to step through them.  Issues 
> similar to the grief I've been going through with signal trampolines.

well....

the current sequence actually is:
current function -> dummy frame -> __gcc_plt_call -> called function

we need to teach gdb that __gcc_plt_call (__d_plt_call) is a stub and
how to unwind through that. i'm thinking about whether this can be done
with the stub unwinder itself or if we need a special unwinder, because
it doesn't follow the same calling conventions as a regular
function/stub. <sigh>

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/