This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]