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

[Philippe Waroquiers <philippe.waroquiers@skynet.be>]

On Mon, 2012-07-23 at 22:16 +0200, Jan Kratochvil wrote:
> On Mon, 23 Jul 2012 22:07:27 +0200, Philippe Waroquiers wrote:
> > Note that the trap instruction should only be written by the
> > push_dummy_code function : for Normal breakpoints, only a Z0 packet
> > should be done, as Valgrind will not allow to modify the guest
> > executable code (it is not mapped writable). 
> 
> I do not understand now what is and what is not allowed for valgrind to write.

The file mapped code (main program, shared libs) is not writable, and
so cannot be modified by Valgrind gdbsrv.

But Valgrind gdbsrv can modify all the memory which is writable.
So, a.o. it can modify the stack.

> 
> For the inferior call to work at all you have to create the stack frame for
> it, otherwise it cannot work, at least for parameters passed by stack.
> 
> 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.

> 
> (Yes, I should read valgrind source code instead.)
> 
> IIUC the 'hlt' cleanup patch can go only for 7.6 as 7.5 should not regress
> with new/fixed valgrind.
infcall Valgrind gdbsrv tests are (currently) regressing with 7.4.91
It would be nice to have it fixed in 7.5 (so that no user can encounter
the nasty error message output by Valgrind) but this is not a critical
blocking problem.
So, up to you to see in which GDB release it can go.

If there will be a clean solution in GDB (7.5 or 7.6), then I will not
commit the kludge in Valgrind.

Philippe