From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25278 invoked by alias); 25 Jul 2012 21:46:19 -0000 Received: (qmail 25269 invoked by uid 22791); 25 Jul 2012 21:46:19 -0000 X-SWARE-Spam-Status: No, hits=-3.1 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; Wed, 25 Jul 2012 21:46:05 +0000 X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIBALVoEFBR9qAt/2dsb2JhbAANOIVxsUCFRAEBAQMBI1YQCxgCAiYCAlcGiBqne26TQIEgkA+BEgOedIlD 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; 25 Jul 2012 23:46:03 +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: <20120725212653.GC2767@adacore.com> References: <20120722173053.GA22036@host2.jankratochvil.net> <1342983655.2301.55.camel@soleil> <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> Content-Type: text/plain; charset="UTF-8" Date: Wed, 25 Jul 2012 21:46:00 -0000 Message-ID: <1343252775.2240.51.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/msg00596.txt.bz2 On Wed, 2012-07-25 at 14:26 -0700, Joel Brobecker wrote: > > The translated block is then continued <<< This is the critical info !!! > > I am having trouble understanding why the translated block would > be continued in the case of an inferior function call, since > the code is not to be executed (thanks to resetting the PC to its > original value prior to the inferior function call when reaching > the Z0 breakpoint we inserted). But... The "continued" explanation above is only for normal breakpoints. The "infcall breakpoints" are effectively *not* continued, thanks to GDB changing the program counter. This is what allows the kludgy Valgrind patch to work. > > > So, if it is easy to change GDB to insert 0xcc (for x86 and amd84) > > and the equivalent breakpoint instr for mips32, then that avoids > > the kludgy patch in Valgrind, which is for sure fragile. > > ... if I still understand correctly, as long as we write a valid > instruction at the point where we place the infcall breakpoint, > we should be fine, right? Jan selected the hlt instruction, but > we could go with the breakpoint trap instruction as well (0xcc), > which I think should be simpler to generalize in the future. > It should not matter which instruction is chosen as long as it > fits the available space, since that instruction will never be > executed (thanks to the Z0 packet introducing an official breakpoint > there). A valid instruction is not enough. We need a valid instruction that will cause Valgrind to terminate block translation. The breakpoint trap instruction is ok for that. (0xcc for x86 and amd64, 0x0005000d for mips32). Philippe