[patch/rfc] Try to get dummy calls working on hpux again
Andrew Cagney
cagney@gnu.org
Fri Jun 11 17:30:00 GMT 2004
>>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
More information about the Gdb-patches
mailing list