This is the mail archive of the
mailing list for the GDB project.
Re: Displaced stepping not always working as expected
On Tuesday 20 September 2011 20:54:24, Marc Khouzam wrote:
> 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
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.