Re: GDB 7.4.91 available for testing

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Fri, 20 Jul 2012 22:50:09 +0200, Philippe Waroquiers wrote:
> 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.

Then it may be for example SIGSEGV instead of SIGTRAP but GDB recognizes any
such trap on breakpoint address as a breakpoint hit.


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

As Z0 should insert the 0xcc instruction this issue of never-modified inferior
memory needs to be resolved anyway:

(gdb) monitor help
general valgrind monitor commands:
[...]
(gdb) maintenance info breakpoints 
Num     Type           Disp Enb Address            What
-1      shlib events   keep n   0x0000000004003702 <dl_main+6562> inf 1
-2      shlib events   keep y   0x0000000004003f92 <dl_main+8754> inf 1
[...]
(gdb) set debug remote 1
(gdb) stepi
Sending packet: $Z0,4003f92,1#ab...Packet received: OK
Packet Z0 (software-breakpoint) is supported
[...]
(gdb) show remote Z-packet 
Support for the `Z0' packet is auto-detected, currently enabled.

Maybe it would be enough to treat Z0 packets like Z1 (hardware-breakpoint)
packets?  The valgrind simulator should be able to trap on specified
addresses, shouldn't it?

I am not aware how make GDB to automatically use Z1 packets but I do not have
an idea why it would hurt if Z0 packets behave like Z1 ones.  Just report (on
x86*) PC+1 for SIGTRAP during the breakpoint hit.


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

With current default 'set breakpoint always-inserted auto' (acting like 'off')
GDB continually removes and re-inserts all the breakpoints.  The "grow" check
will not work on breakpoint re-insertions.


Thanks,
Jan