From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23678 invoked by alias); 26 Jul 2012 22:21:43 -0000 Received: (qmail 23667 invoked by uid 22791); 26 Jul 2012 22:21:42 -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 mailrelay002.isp.belgacom.be (HELO mailrelay002.isp.belgacom.be) (195.238.6.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 Jul 2012 22:21:13 +0000 X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIBAI3BEVBR9qAt/2dsb2JhbAANOIVxsUGFLwEBAQMBHQZWBQsLDgoCAiYCAlcGHBKHbBGnTm6TMIEgii+FYoESA55ziUM 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; 27 Jul 2012 00:21:12 +0200 Subject: Re: [patch] [i386] Put hlt at the ON_STACK breakpoint [Re: GDB 7.4.91 available for testing] From: Philippe Waroquiers To: Pedro Alves Cc: Jan Kratochvil , Joel Brobecker , gdb-patches@sourceware.org In-Reply-To: <50113C8D.6090302@redhat.com> References: <20120718163413.GA17548@adacore.com> <1342739016.2220.32.camel@soleil> <20120720071158.GA7053@host2.jankratochvil.net> <1342817409.2149.41.camel@soleil> <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> <50113C8D.6090302@redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 26 Jul 2012 22:21:00 -0000 Message-ID: <1343341285.2258.145.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/msg00648.txt.bz2 On Thu, 2012-07-26 at 13:48 +0100, Pedro Alves wrote: > On 07/25/2012 09:24 PM, Philippe Waroquiers wrote: > > > > There is no way to re-translate the block currently being executed : > > Valgrind has no way to "drop" the translated block it is currently > > executing. > > So if you interrupt valgrind, and then set a breakpoint at or near the > address currently being executed, that breakpoint will be ignored? I'm guessing > there's some mechanism to re-translate and hook a new block to handle that case. Yes, such breakpoints will be ignored (in some cases). It depends how GDB regained control (interrupt while running, or due to Valgrind reporting an error, or interrupted while all threads are in a syscall). I would have liked to find a reasonable solution working in all cases, but could not find one. => due to this lack, the option to to activate the Valgrind gdbsrv has 3 values: --vgdb=no (gdbsrv is not active) --vgdb=yes (default value, neglectible overhead compared to =no) --vgdb=full (a lot slower == 500% slower, it always puts a helper function call for each instruction). With this, breakpoints will not be ignored and debugging will be as precise as possible. See http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver-limitations > > > So, a breakpoint cannot be translated using a 0xCC because when GDB > > tells to continue after the breakpoint, there is no way to retranslate > > the original instructions (without the 0xCC) as long as the block > > is being executed. > > Which would sound like a similar issue. Is this a current limitation, > or something that Will Never Work? Yes, it is the same issue. Currently, it is in state Will Never Work, as I have no idea how to properly attack this without deep changes in Valgrind core. > Why doesn't Valgrind trigger a translation of blocks with breakpoints > as soon as a Z0 is inserted? That way, when the forced infcall returns, > it'd find a translated breakpoint already, even without a 0xcc inserted, > instead of valgrind finding that the block hadn't been translated yet, > and ending up translating a random, possibly invalid instruction. When a Z0 is received, Valgrind gdbsrv immediately marks that the address in the Z0 has to be re-translated. But that will not happen as long as the control is not returned to the Valgrind "scheduler" (kind of main loop translating and executing the translated blocks). Philippe