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

[Randolph Chung <randolph@tausq.org>]

> Ah! the comments should include this diagram, I think making this clear 
> (and the need to fudge __gcc_plt_call) is what's really needed.

how about this?

+  /* On HPUX, functions in the main executable and in libraries can be located
+     in different spaces.  In order for us to be able to select the right
+     space for the function call, we need to go through an instruction seqeunce
+     to select the right space for the target function, call it, and then
+     restore the space on return.
+
+     There are two helper routines that can be used for this task -- if
+     an application is linked with gcc, it will contain a __gcc_plt_call
+     helper function.  __gcc_plt_call, when passed the entry point of an
+     import stub, will do the necessary space setting/restoration for the
+     target function.
+
+     For programs that are compiled/linked with the HP compiler, a similar
+     function called __d_plt_call exists; __d_plt_call expects a PLABEL instead
+     of an import stub as an argument.
+
+     To summarize, the call flow is:
+       current function -> dummy frame -> __gcc_plt_call (import stub)
+                        -> target function
+     or
+       current function -> dummy frame -> __d_plt_call (plabel)
+                        -> target function
+
+     In general the "funcaddr" argument passed to push_dummy_code is the actual
+     entry point of the target function.  For __gcc_plt_call, we need to
+     locate the import stub for the corresponding function.  Failing that,
+     we construct a dummy "import stub" on the stack to pass as an argument.
+     For __d_plt_call, we similarly synthesize a PLABEL on the stack to
+     pass to the helper function.
+
+     An additional twist is that, in order for us to restore the space register
+     to its starting state, we need __gcc_plt_call/__d_plt_call to return
+     to the instruction where we started the call.  However, if we put
+     the breakpoint there, gdb will complain because it will find two
+     frames on the stack with the same (sp, pc) (with the dummy frame in
+     between).  Currently, we set the return pointer to (pc - 4) of the
+     current function.  FIXME: This is not an ideal solution; possibly if the
+     current pc is at the beginning of a page, this will cause a page fault.
+     Need to understand this better and figure out a better way to fix it.  */

> Yes.  Probably using the tramp-frame logic.

tramp-frame doesn't handle frames that are "functions" (that have a
name). I think we should make that an attribute of the tramp-frame
(whether having a name is ok or not?)

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