From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1569 invoked by alias); 19 Jul 2012 23:02:59 -0000 Received: (qmail 1561 invoked by uid 22791); 19 Jul 2012 23:02:58 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,TW_XC X-Spam-Check-By: sourceware.org Received: from mailrelay011.isp.belgacom.be (HELO mailrelay011.isp.belgacom.be) (195.238.6.178) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 19 Jul 2012 23:02:44 +0000 X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAJGRCFBR9oWA/2dsb2JhbAANOIVutwQBAQEEIwRSEAsYAgImAgJXBrMsbpJ8gSCPeoESA6gu Received: from 128.133-246-81.adsl-dyn.isp.belgacom.be (HELO [192.168.1.2]) ([81.246.133.128]) by relay.skynet.be with ESMTP; 20 Jul 2012 01:02:42 +0200 Subject: Re: GDB 7.4.91 available for testing From: Philippe Waroquiers To: Joel Brobecker Cc: gdb@sourceware.org In-Reply-To: <20120718163413.GA17548@adacore.com> References: <20120718163413.GA17548@adacore.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 19 Jul 2012 23:02:00 -0000 Message-ID: <1342739016.2220.32.camel@soleil> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-07/txt/msg00053.txt.bz2 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