[RFA/hppa] Fix pb in inferior function call

[Joel Brobecker <brobecker@gnat.com>]

[-- Attachment #1: Type: text/plain, Size: 2851 bytes --]

Hello,

I was trying to understand the source of the following problem
(extracted from call-rt-st.exp):

     (gdb) p print_struct_rep (*struct1)
     Contents of struct1: 
     
             22         0
     dummy-frame.c:304: internal-error: dummy_frame_prev_register: Assertion `dummy != NULL' failed.
     A problem internal to GDB has been detected,
     further debugging may prove unreliable.
     Quit this debugging session? (y or n) n
     
     dummy-frame.c:304: internal-error: dummy_frame_prev_register: Assertion `dummy != NULL' failed.
     A problem internal to GDB has been detected,
     further debugging may prove unreliable.
     Create a core file of GDB? (y or n) n
     
     dummy-frame.c:304: internal-error: dummy_frame_prev_register: Assertion `dummy != NULL' failed.
     A problem internal to GDB has been detected,
     further debugging may prove unreliable.
     Quit this debugging session? (y or n) n
     
     dummy-frame.c:304: internal-error: dummy_frame_prev_register: Assertion `dummy != NULL' failed.
     A problem internal to GDB has been detected,
     further debugging may prove unreliable.
     Create a core file of GDB? (y or n) n

The assertion fails because we fail to locate the dummy_frame
in our dummy_frame_stack. The reason for the failure is that
the TOS stored in the dummy_frame we saved is different from
the stack_addr of the frame_id we built for the dummy_frame.
It's off by a few bytes.

The stack_addr for the dummy frame is computed by reading the Stack
Pointer register. The TOS value is the value of SP after the dummy
frame has been pushed.

If I understand correctly how this is all supposed to work, I think
we simply forgot to update the value of the SP register. Because the
function doesn't read its parameters from the stack (the struct is
passed via 2 registers), we don't see any noticeable effect on the
execution of the function we called. However, when we reach our
end-of-inferior-function-call, the value of the SP is back to the
original value, which doesn't match the saved TOS.

2004-04-30  J. Brobecker  <brobecker@gnat.com>

        * hppa-tdep.c (hppa32_push_dummy_call): Set the Stack Pointer.
        (hppa64_push_dummy_call): Likewise.

The change has been tested on hppa32-hpux11.00, and it fixes roughly
500 regressions (yay! :-). It also brings the duration of the testsuite
run from several hours down to about 45 mins.

I didn't test the change for hppa64, but it seems pretty obvious if
the hppa32 one is correct.

OK to apply?

Thanks,
-- 
Joel

PS: My main objective is to get the frame code stable enough so that
    the patch I was working on to detect that we stopped inside a
    function call using frame IDs works without regressions on HP/UX.
    I didn't realize I would open such a can of worms when I first
    started on this path... :-/

[-- Attachment #2: hppa-tdep.c.diff --]
[-- Type: text/plain, Size: 1041 bytes --]

Index: hppa-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
retrieving revision 1.136
diff -u -p -r1.136 hppa-tdep.c
--- hppa-tdep.c	7 Mar 2004 19:58:27 -0000	1.136
+++ hppa-tdep.c	31 Mar 2004 03:57:30 -0000
@@ -911,6 +911,9 @@ hppa32_push_dummy_call (struct gdbarch *
   /* Set the return address.  */
   regcache_cooked_write_unsigned (regcache, RP_REGNUM, bp_addr);
 
+  /* Update the Stack Pointer.  */
+  regcache_cooked_write_unsigned (regcache, SP_REGNUM, param_end + 32);
+
   /* The stack will have 32 bytes of additional space for a frame marker.  */
   return param_end + 32;
 }
@@ -1031,6 +1034,9 @@ hppa64_push_dummy_call (struct gdbarch *
 
   /* Set the return address.  */
   regcache_cooked_write_unsigned (regcache, RP_REGNUM, bp_addr);
+
+  /* Update the Stack Pointer.  */
+  regcache_cooked_write_unsigned (regcache, SP_REGNUM, param_end + 64);
 
   /* The stack will have 32 bytes of additional space for a frame marker.  */
   return param_end + 64;