Re: GDB 7.4.91 available for testing

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

On Fri, 2012-07-20 at 09:11 +0200, Jan Kratochvil wrote:
> On Fri, 20 Jul 2012 01:03:36 +0200, Philippe Waroquiers wrote:
> > The Valgrind gdbserver is handling Z0 and Z1 packets to insert
> > breakpoints. So, GDB inserts a breakpoint on the stack using
> > a Z0 packet. However, from what I can see, no 0xcc instruction
> > has been written on the stack by GDB.
> 
> The Z0 packet instructs gdbserver to put 0xcc there,
> linux-x86-low.c:x86_breakpoint.  gdbserver does it.
Thanks for the clarification.
I now understand that my expectation to have GDB writing 0xCC was quite
wrong: if GDB would be responsible to write 0xCC, then why would a Z0
packet be needed ?

Note that I am wondering how this ON_STACK technique works.
E.g. on gcc20, readelf -a indicates the GNU_STACK is RW, but not E or X
or similar.

In any case, with this better understanding, I see no other solution
than to have the Valgrind gdbserver writing a breakpoint instruction
at the Z0 provided address (even if with the current technique Valgrind
gdbserver uses to implement breakpoints, this instruction will in fact
never be executed but only translated).

The tricky part will be to guess that a breakpoint is for the
'return address for an inferior call', as Valgrind is not expected
(or allowed) to modify the code sections of the guest client being
executed.

For this guess, I am thinking to use the following conditions:
    1. the stack pointer in the register cache has been changed
       to grow the stack
  and
    2. the breakpoint address is in this "grown zone" 

Comments/feedback on the above ?

Thanks

Philippe