Re: [patch] [i386] Put hlt at the ON_STACK breakpoint [Re: GDB 7.4.91 available for testing]

Philippe Waroquiers
2012-07-26T22:21:43Z

On Thu, 2012-07-26 at 13:48 +0100, Pedro Alves wrote:
> On 07/25/2012 09:24 PM, Philippe Waroquiers wrote:
> >
> > There is no way to re-translate the block currently being executed :
> > Valgrind has no way to "drop" the translated block it is currently
> > executing.
>
> So if you interrupt valgrind, and then set a breakpoint at or near the
> address currently being executed, that breakpoint will be ignored? I'm guessing
> there's some mechanism to re-translate and hook a new block to handle that case.
Yes, such breakpoints will be ignored (in some cases). It depends
how GDB regained control (interrupt while running, or due to Valgrind
reporting an error, or interrupted while all threads are in a syscall).

I would have liked to find a reasonable solution working in all
cases, but could not find one.
=> due to this lack, the option to to activate the Valgrind gdbsrv
has 3 values:
--vgdb=no (gdbsrv is not active)
--vgdb=yes (default value, neglectible overhead compared to =no)
--vgdb=full (a lot slower == 500% slower,
it always puts a helper function call for
each instruction).
With this, breakpoints will not be ignored
and debugging will be as precise as possible.
See
http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver-limitations

>
> > So, a breakpoint cannot be translated using a 0xCC because when GDB
> > tells to continue after the breakpoint, there is no way to retranslate
> > the original instructions (without the 0xCC) as long as the block
> > is being executed.
>
> Which would sound like a similar issue. Is this a current limitation,
> or something that Will Never Work?
Yes, it is the same issue. Currently, it is in state Will Never Work,
as I have no idea how to properly attack this without deep changes
in Valgrind core.

> Why doesn't Valgrind trigger a translation of blocks with breakpoints
> as soon as a Z0 is inserted? That way, when the forced infcall returns,
> it'd find a translated breakpoint already, even without a 0xcc inserted,
> instead of valgrind finding that the block hadn't been translated yet,
> and ending up translating a random, possibly invalid instruction.
When a Z0 is received, Valgrind gdbsrv immediately marks that the
address in the Z0 has to be re-translated.
But that will not happen as long as the control is not returned to the
Valgrind "scheduler" (kind of main loop translating and executing the
translated blocks).

Philippe