This is the mail archive of the
mailing list for the GDB project.
Re: Displaced stepping not always working as expected
On Tue, 2011-09-20 at 15:54 -0400, Marc Khouzam wrote:
> Can someone let me know where in GDB I can look to see why a displaced
> instruction is not being executed? Or maybe other debug logs to enable?
Usually, I use 'set debug displaced 1' and 'set debug infrun 1'
together. Looks you have used them. I don't know extra debug log to
> 'next' operation stuck at line 9 of my program:
> (gdb) n
> infrun: clear_proceed_status_thread (Thread 0x40b21940 (LWP 763))
> infrun: proceed (addr=0xffffffffffffffff, signal=144, step=1)
> infrun: resume (step=1, signal=0), trap_expected=1
> displaced: stepping Thread 0x40b21940 (LWP 763) now
> displaced: saved 0x4006d2: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0
> displaced: copy 0x40083e->0x4006d2: 83 6d fc 01 8b 75 fc bf 8c 09 40 00 b8 00 00 00
> displaced: displaced pc to 0x4006d2
> displaced: run 0x4006d2: 83 6d fc 01
> infrun: target_wait (-1, status) =
> infrun: 760 [Thread 0x40b21940 (LWP 763)],
> infrun: status->kind = stopped, signal = SIGTRAP
> infrun: Switching context from Thread 0x40b21940 (LWP 763) to Thread 0x40b21940 (LWP 763)
The line of log looks strange to me. Why LWP 763 switch to itself?
Usually, what I saw here is "from Thread A to Thread B", while A != B.
In this case, I know current displaced stepping infrastructure doesn't
handle "thread context switch during displaced stepping". That is, when
some insns are copied to scratch pad and executed in thread A, but
thread B gets an event first. Then gdb will forget that Thread A is
displaced stepping after handle event for Thread B. This problem is
quite similar to context switch during software-single-step.
I don't think this is the same problem you asked here. I had drafted a
patch for this problem I described above, but still need some time.