From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11666 invoked by alias); 26 Jul 2012 21:56:20 -0000 Received: (qmail 11638 invoked by uid 22791); 26 Jul 2012 21:56:19 -0000 X-SWARE-Spam-Status: No, hits=-3.1 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,TW_QE X-Spam-Check-By: sourceware.org Received: from mailrelay009.isp.belgacom.be (HELO mailrelay009.isp.belgacom.be) (195.238.6.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 Jul 2012 21:56:05 +0000 X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIBAK+7EVBR9qAt/2dsb2JhbAANOIVxsUGFLwEBAQMBI1YFCwsaAiYCAlcGiBqnZG6TLIEgkBGBEgOec4lD Received: from 45.160-246-81.adsl-dyn.isp.belgacom.be (HELO [192.168.1.2]) ([81.246.160.45]) by relay.skynet.be with ESMTP; 26 Jul 2012 23:56:04 +0200 Subject: Re: [patch] [i386] Put hlt at the ON_STACK breakpoint [Re: GDB 7.4.91 available for testing] From: Philippe Waroquiers To: Joel Brobecker Cc: Pedro Alves , Jan Kratochvil , gdb-patches@sourceware.org In-Reply-To: <20120725223933.GD2767@adacore.com> References: <20120723072125.GA12958@host2.jankratochvil.net> <20120723155951.GA24718@adacore.com> <20120723163513.GA1222@host2.jankratochvil.net> <1343074047.2209.23.camel@soleil> <20120723201611.GA19567@host2.jankratochvil.net> <1343075809.2209.53.camel@soleil> <501009AE.40901@redhat.com> <1343247870.2240.29.camel@soleil> <20120725212653.GC2767@adacore.com> <1343252775.2240.51.camel@soleil> <20120725223933.GD2767@adacore.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 26 Jul 2012 21:56:00 -0000 Message-ID: <1343339768.2258.126.camel@soleil> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-07/txt/msg00647.txt.bz2 On Wed, 2012-07-25 at 15:39 -0700, Joel Brobecker wrote: > What I am trying to do, is make sure that new GDB versions work well > with older versions of valgrind (although, isn't gdbserver support > relatively recent?), while at the same time trying to make future > versions of valgrind more robust. I don't know how long we are going > to be able to keep the workaround. What if other tools implementing > the remote protocol had the same problem, and they required us to > insert a different instruction instead? Valgrind gdbsrv appeared in the last Valgrind version (3.7.0). If GDB modifies the stack to put a 0xCC, that should work with old Valgrind (I will test in any case). Otherwise, effectively, it is always possible that another "strange" gdbserver must have another instruction. I imagine however that a breakpoint trap instruction will be the most likely common denominator amongst "strange" gdbserver. The other "strange" gdbsrv I know about is the qemu one. Just tried to build the last qemu to see how it works, but build failed. Philippe