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]

[RFA/alpha] Fetch register from the right frame


Hello,

Trying to switch to gdb-6.3 on alpha-tru64, we noticed the following
problem:

    (gdb) bt
    #0  0x000003ff8057d43c in __hstTransferRegistersPC ()
       from /usr/shlib/libpthread.so
    #1  0x000003ff8056e8e4 in __osTransferContext ()
       from /usr/shlib/libpthread.so
    #2  0x000003ff80560c30 in __dspDispatch () from /usr/shlib/libpthread.so
    #3  0x000003ff80560178 in __cvWaitPrim () from /usr/shlib/libpthread.so
    #4  0x000003ff8055da9c in __pthread_cond_wait ()
       from /usr/shlib/libpthread.so
    #5  0x000000012002cf50 in system.tasking.rendezvous.wait_for_call ()
        at s-tasren.adb:6
    #6  0x00000001200296ec in system.tasking.rendezvous.accept_trivial ()
        at s-tasren.adb:6
    #7  0x000000012001e204 in task_switch.callee (<_task>=Cannot access memory at address 0x28
    ) at task_switch.adb:29
    warning: Previous frame inner to this frame (corrupt stack?)

The two symptoms of the same problem are:

  . "<_task>=Cannot access memory at address 0x28" at frame #7
  . warning: Previous frame inner to this frame (corrupt stack?)

The callstack is missing the following two frames:

    #8  0x0000000120027cfc in system.tasking.stages.task_wrapper ()
        at s-tassta.adb:6
    #9  0x000003ff8058a47c in __thdBase () from /usr/shlib/libpthread.so

I tracked the problem to alpha_heuristic_frame_prev_register():
Basically, after having verified that the register we'd like to fetch
has not been saved in by the next frame, we try to fetch the value
of the register inside the next frame. But instead, what we do, is
that we actually fetch the value of the register for the frame
*following* the next frame. Oups!

In our case above, instead of fetching the value of FP in
__pthread_cond_wait(), we end up fetching its value from __cvWaitPrim,
which contains the following instruction:

        0x000003ff8055fc58 <__cvWaitPrim+72>:   clr     fp

So the value of FP becomes incorrect, and causes the backtrace
screwup later down the road when we try to read RA using an offset
from FP.

2004-11-30  Joel Brobecker  <brobecker@gnat.com>

        * alpha-tdep.c (alpha_heuristic_frame_prev_register): Fetch
        the register value from the correct frame.

Tested on alpha-tru64 5.1, fixes the problem above, no regression
in the testsuite.

OK to apply?

Thanks,
-- 
Joel

Attachment: reg.diff
Description: Text document


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