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

[Pedro Alves <palves@redhat.com>]

On 07/25/2012 09:24 PM, Philippe Waroquiers wrote:
> On Wed, 2012-07-25 at 15:58 +0100, Pedro Alves wrote:
>> On 07/23/2012 09:36 PM, Philippe Waroquiers wrote:
>>
>>>> So the GDB patch is no longer needed when you have fixed valgrind to put 0xcc
>>>> during Z0? Why valgrind cannot write 0xcc into stack memory when it already
>>>> has to write there to create the stack frame / parameters passed by stack?
>>> Effectively, I have a patch which fixes the problem.
>>> But the patch is a kludge which heuristically guesses that GDB is
>>> pushing an infcall.
>>
>> Why do you have to guess that, rather than just detecting a breakpoint is
>> being set on a stack (or non text) address?  If something sets a breakpoint
>> in a data address, it is basically telling valgrind "this is actually code".
> 
> This is explained by the way Valgrind gdbsrv (must) implement
> breakpoints.
> (this is a little bit tricky, as it is linked to Valgrind internals).
> 
> Valgrind translates guest code instructions in small blocks.
> As part of the translation, if there is a breakpoint at addr XXXX
> then the translation of address XXXX will start with a call to a
> helper function which reports to GDB that a breakpoint has been
> encountered. This function then reads/executes protocol packets till a
> continue packet is received.
> The translated block is then continued <<< This is the critical info !!!
> 
> 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.

> 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?

> So, for normal breakpoints, Valgrind gdbsrv cannot insert 0xCC, as this
> would just not work.
> 
> "Normal" breakpoints on the stack (trampoline code or whatever) or
> JITted code or ... must be handled the same way: V gdbsrv cannot
> touch the code to handle breakpoints.
> 
> The only special case in which Valgrind gdbsrv can insert a 0xCC is
> when it is sure that this code will *not* be executed.
> This is the case for the 0xcc for the push_dummy_code.
> This code will not be executed because GDB will change the pc register.

"this code" is a bit ambiguous in this sentence.  You mean, the code that
was there if we didn't put a 0xcc in place, I presume.

> When the continue packet is received, the execution of the block is
> then not continued, instead the continue will cause a jump to the
> "original pc" (the one before the infcall).
>
> So, if it is easy to change GDB to insert 0xcc (for x86 and amd84)
> and the equivalent breakpoint instr for mips32, then that avoids
> the kludgy patch in Valgrind, which is for sure fragile.

It adds a kludgy patch in GDB, for what sounds like a current Valgrind
limitation, so I'd like to explore all possibilities.

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.

-- 
Pedro Alves