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

[Andrew Cagney <cagney@gnu.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

Yes, thanks!  Suggest wrapping this bit in

*NOINDENT*
...
*INDENT*

so that you're safe from gdb_indent.sh.

> +     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.  */

with that addition, it's ok to commit.

>>> 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?)

I was thinking of the case where the stub was pushed onto the stack - 
that doesn't have a name.

Andrew