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] |
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:
hppa-tdep.c.diff
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |