Re: GDB 7.4.91 available for testing

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

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