GDB 7.4.91 available for testing

GDB 7.4.91 available for testing

[Joel Brobecker]

Hello,

I have just finished creating the gdb-7.4.91 pre-release.
It is available for download at the following location:

    ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-7.4.91.tar.bz2

A gzip'ed version is also available: gdb-7.4.91.tar.gz.

Please give it a test if you can and report any problems you might find.

On behalf of all the GDB contributors, thank you!

-- 
Joel

Re: GDB 7.4.91 available for testing

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 728 bytes --]

On Wednesday 18 July 2012 12:34:13 Joel Brobecker wrote:
> I have just finished creating the gdb-7.4.91 pre-release.
> It is available for download at the following location:
> 
>     ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-7.4.91.tar.bz2
> 
> A gzip'ed version is also available: gdb-7.4.91.tar.gz.
> 
> Please give it a test if you can and report any problems you might find.

seems ok for sim and these targets:
 arm-elf
 avr-elf
 bfin-elf
 cr16-elf
 cris-elf
 d10v-elf
 frv-elf
 h8300-elf
 iq2000-elf
 lm32-elf
 m32c-elf
 m32r-elf
 m68hc11-elf
 mcore-elf
 microblaze-elf
 mips-elf
 mn10300-elf
 moxie-elf
 ppc-elf
 rl78-elf
 rx-elf
 sh64-elf
 sh-elf
 sparc-elf
 v850-elf
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: GDB 7.4.91 available for testing

[Philippe Waroquiers]

On Wed, 2012-07-18 at 09:34 -0700, Joel Brobecker wrote:
> Hello,
> 
> I have just finished creating the gdb-7.4.91 pre-release.
> It is available for download at the following location:
> 
>     ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-7.4.91.tar.bz2
> 
> A gzip'ed version is also available: gdb-7.4.91.tar.gz.
> 
> Please give it a test if you can and report any problems you might find.

The new version causes a regression with the Valgrind gdbserver.

At least on x86 and on amd64, the Valgrind regression tests for
inferior calls in the Valgrind gdbserver are failing as
Valgrind reports errors such as:
vex x86->IR: unhandled instruction bytes: 0xF 0x21 0x0 0xC0.
(inferior calls are working with GDB 7.4).

I believe this difference is caused by the fact that infcall.c
has switched from AT_ENTRY_POINT to ON_STACK technique for the
breakpoint for the fake return address of the pushed function call.

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.

When a function call returns, Valgrind translates and instrument
(if not yet done) the instructions at the return address.
(if there is a break at this address, the instrumented code
will start with a call to a Valgrind helper function which reports
the breakpoint to GDB and reads remote protocol packets).

In case of the fake return address on the stack, I believe no
instruction was effectively written by GDB (i.e. no 0xcc was written).
So, when the return instruction of the pushed fn call is executed,
Valgrind tries to translate and instrument what is on the stack at
the return address, and then finds whatever random or invalid
instruction bytes and then reports the above error.

I do not see a clean/easy way to solve this problem.
The only way I see (quite ugly, machine dependent, ...) will be for
Valgrind gdbserver to guess that a breakpoint on the stack
(when the stack was just increased before by changing sp) implies
to write a valid dummy instruction on the stack to allow
the Valgrind translator to work properly.
It is not yet clear how to implement the above guess properly,
and I do not like the idea to have Valgrind gdbserver writing
itself dummy or break instructions on the stack (such work/knowledge
is better done by GDB).

Is there anything easier which could be done at GDB 
and/or by having Valgrind gdbserver handling differently some
protocol packets ?

(of course, I suppose there was a very good reason to switch to
ON_STACK technique and that switching back is not an option).

Philippe

Re: GDB 7.4.91 available for testing

[Jan Kratochvil]

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,
Jan

Re: GDB 7.4.91 available for testing

[Philippe Waroquiers]

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

Re: GDB 7.4.91 available for testing

[Jan Kratochvil]

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

Re: GDB 7.4.91 available for testing

[Philippe Waroquiers]

On Sun, 2012-07-22 at 19:30 +0200, Jan Kratochvil wrote:
> On Fri, 20 Jul 2012 22:50:09 +0200, Philippe Waroquiers wrote:
> > 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:
Currently, Valgrind does not (and cannot) modify the guest code
(e.g. as the guest code might not be mapped writable). Also, modifying
the guest code for a breakpoint would introduce a lot of difficulties
(e.g. the translated code would have to be dropped and re-translated
when stepping over the breakpoint, and that is currently not possible).

So, breakpoints are implemented in Valgrind by having a helper function
call inserted in the translated code as a "preamble" to the instruction
at which a breakpoint is placed. E.g. the below is the translated code
if there is a break on 0x8048BDA.
   ------ IMark(0x8048BDA, 7, 0) ------ 
   PUT(68) = 0x8048BDA:I32
   DIRTY 1:I1 RdFX-gst(24,4) MoFX-gst(68,4) ::: VG_(helperc_CallDebugger)[rp=1]{0x38072280}(0x8048BDA:I32)
   t7 = GET:I32(376)
   t0 = GET:I32(24)
   ...
The PUT(68) is an assignment to the (virtual) program counter register.
The helperc fn will indicate to GDB that a breakpoint is encountered,
and will read further gdbsrv protocol packets, till a "continue" packet
is received (and then the instructions following the helperc 
are then executed).


> 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?
Z0 and Z1 packets are handled the same way by Valgrind gdbserver
(see above).
The problem with the above technique is that there is no valid
instruction at the ON_STACK breakpoint address, and the valgrind
translator does not like this.

Implementing breakpoints with "real" trap would imply to
have the Valgrind encoder/decoder to understand the gdbserver breakpoint
concept, which is not ok with regards to software dependencies.

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

The "grow" check just has to work for the ON_STACK breakpoints
(as the other "normal" breakpoints are supposed to be done at an address
where there is valid code that Valgrind can translate).

The "grow" check is also only done if GDB has modified the stack
pointer register (e.g. using a "P" packet) between the "stop" and
"continue".
So, normal stack growth (during execution) is not taken into account in
this guess.

I just implemented the "grow" check and tested on the x86/amd64/mips
platforms (ppc32/64, s390x and arm seems to be AT_ENTRY_POINT
platforms).

The Valgrind gdbsrv regression tests are now passing with GDB 7.4.91
without error messages, so it looks at least to improve.

The doubt I have is that an inferior function call from GDB
might imply several "low level" calls (e.g. first a call to malloc
to allocate some memory for the argument(s), followed by the
real fn call).
Currently, the guess only works for the first low level call.
But it looks like the next low level call is using the same return
breakpoint address (by chance maybe ?) and so the first guess has
placed a 0xcc at this address, and Valgrind translator is happy.

Is it by chance that successive low level calls (for the same "user
inferior call") are using the same stack address as return address ?

Thanks again for the help/explanations about Z0, I was a little bit
lost in the GDB behaviour

Philippe

Re: GDB 7.4.91 available for testing

[Jan Kratochvil]

[ Moved to gdb-patches:
  [patch] [i386] Put hlt at the ON_STACK breakpoint [Re: GDB 7.4.91 available for testing]
  http://sourceware.org/ml/gdb-patches/2012-07/msg00436.html
]