Re: Displaced stepping not always working as expected

[Pedro Alves <pedro@codesourcery.com>]

On Tuesday 20 September 2011 20:54:24, Marc Khouzam wrote:
> Hi,
> 
> I just need a hint on where next to look...

> I've been asked to look into problems with non-stop on 
> a user-mode-linux virtual machine
> (http://user-mode-linux.sourceforge.net/)

So does this only happen with UML?  UML uses ptrace internally for
its own business, I wouldn't be surprised if there's something
wonky going on at that level.

> On that AMD 64bit machine, I cannot step or resume past a breakpoint
> when using non-stop with a multi-threaded program _if_ any of the
> threads is still running.  If I interrupt all threads, then displaced
> stepping works.

I wouldn't be surprised if the UM kernel is reporting a spurious
SIGTRAP to gdb.  Try "set debug lin-lwp 1" as well, but I don't
think it'll tell you much.  Maybe peeking at eflags or the siginfo
of that SIGTRAP reveals something.

> During the failure case, I confirmed that the displaced
> instruction does _not_ get executed (the memory it should have 
> changed stays the same).  So, the PC stays in the same place
> and the step does not move forward.
> 
> I tried to turn on 'set debug infrun 1', but I get the exact same
> logs during the failure as during a success case.
> 
> Sometimes, if I keep trying to step, it will finally work (could be
> after 3 attempts, could be after 100 attempts or more).  It seems
> related to what the other running thread is doing at the time.
> 
> 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?

Try "set debug lin-lwp 1", and see if the resume was preempted and
for some bizarre reason the core is getting a cached wait status
instead of really resuming the thread.

Otherwise, this smells like a UML problem.

-- 
Pedro Alves