Re: [rfc] dummy calls for hppa64-hpux

[Randolph Chung <randolph@tausq.org>]

In reference to a message from Randolph Chung, dated Dec 08:
> this patch is not yet ready for inclusion, i'm only posting it for
> comments because it's rather unorthodox.

ok, here's another unfinished idea..... Dave Anglin suggested an
alternative scheme to me that seems more robust.  I haven't written the
code for it yet, but here's a 50-line comment to explain it. Comments
before i try it? :)


   /* In order to make an interspace call, we need to go through a stub.
      gcc supplies an appropriate stub called "__gcc_plt_call", however, if
      an application is compiled with HP compilers then this stub is not
      available.  We used to fallback to "__d_plt_call", however that stub
      is not entirely useful for us because it doesn't do an interspace
      return back to the caller.  In order to keep the code uniform, we
      instead don't use either of these stubs, but instead write our own
      onto the stack.

      A problem arises since the stack is located in a different space than
      code, so in order to branch to a stack stub, we will need to do an
      interspace branch.  Previous versions of gdb did this by modifying code
      at the current pc and doing single-stepping to set the pcsq.  Since this
      is highly undesirable, we use a different scheme:

      All we really need to do the branch to the stub is a short instruction
      sequence like this:

      PA1.1:
                ldsid (rX),r1
                mtsp r1,sr0
                be,n (sr0,rX)

      PA2.0:
                bve,n (sr0,rX)

      Instead of writing these sequences ourselves, we can find it in
      the instruction stream that belongs to the current space.  While this
      seems difficult at first, we are actually guaranteed to find the sequences
      in several places:

      - in export stubs for shared libraries
      - For 32-bit code, in the "noshlibs" routine in the main module
      - For 64-bit code, in the "$START$" routine in the main module

      (Note that we can cache the address of these sequences in
      the objfile's private data.)

      So, what we do is:
      - write a stack trampoline
      - look for a suitable instruction sequence in the current space
      - point the sequence at the trampoline
      - set the return address of the trampoline to the current instruction (*)
      - set the continuing address of the "dummy code" as the sequence.

      (*) An additional twist is that, in order for us to restore the space
      register to its starting state, we need the trampoline 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.  */

Is this better? :)

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