Re: Displaced stepping not always working as expected

[Yao Qi <yao@codesourcery.com>]

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
turn on.

>                                ^^^^^^^^
> '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.