From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31159 invoked by alias); 25 Jul 2012 20:24:40 -0000 Received: (qmail 31144 invoked by uid 22791); 25 Jul 2012 20:24:38 -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 Mailrelay020.isp.belgacom.be (HELO mailrelay020.isp.belgacom.be) (195.238.6.95) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Jul 2012 20:24:20 +0000 X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwBACZVEFBR9qAt/2dsb2JhbAANOIVxsAuBNIVEAQEBBCNWEAsOCgICJgICVwawAG6TMIEgii2FYoESA550iUM 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 22:24:19 +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: <501009AE.40901@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> Content-Type: text/plain; charset="UTF-8" Date: Wed, 25 Jul 2012 20:24:00 -0000 Message-ID: <1343247870.2240.29.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/msg00584.txt.bz2 On Wed, 2012-07-25 at 15:58 +0100, Pedro Alves wrote: > On 07/23/2012 09:36 PM, Philippe Waroquiers wrote: > > >> So the GDB patch is no longer needed when you have fixed valgrind to put 0xcc > >> during Z0? Why valgrind cannot write 0xcc into stack memory when it already > >> has to write there to create the stack frame / parameters passed by stack? > > Effectively, I have a patch which fixes the problem. > > But the patch is a kludge which heuristically guesses that GDB is > > pushing an infcall. > > Why do you have to guess that, rather than just detecting a breakpoint is > being set on a stack (or non text) address? If something sets a breakpoint > in a data address, it is basically telling valgrind "this is actually code". This is explained by the way Valgrind gdbsrv (must) implement breakpoints. (this is a little bit tricky, as it is linked to Valgrind internals). Valgrind translates guest code instructions in small blocks. As part of the translation, if there is a breakpoint at addr XXXX then the translation of address XXXX will start with a call to a helper function which reports to GDB that a breakpoint has been encountered. This function then reads/executes protocol packets till a continue packet is received. The translated block is then continued <<< This is the critical info !!! 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, 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. So, for normal breakpoints, Valgrind gdbsrv cannot insert 0xCC, as this would just not work. "Normal" breakpoints on the stack (trampoline code or whatever) or JITted code or ... must be handled the same way: V gdbsrv cannot touch the code to handle breakpoints. The only special case in which Valgrind gdbsrv can insert a 0xCC is when it is sure that this code will *not* be executed. This is the case for the 0xcc for the push_dummy_code. This code will not be executed because GDB will change the pc register. When the continue packet is received, the execution of the block is then not continued, instead the continue will cause a jump to the "original pc" (the one before the infcall). So, in summary: * for all normal breakpoints, Valgrind gdbsrv cannot insert a 0xcc * for "dummy inferior call return breakpoint", Valgrind gdbsrv can insert a 0xcc, as GDB will ensure this piece of code is not executed, and so there is no need to re-translate it without the 0xcc So, the kludge patch I have done tries to guess if the breakpoint on the stack is a normal breakpoint (so, V gdbsrv cannot touch it) or is a "infcall" breakpoint (then the kludge patch inserts a 0xcc). It would be much cleaner to have GDB inserting the 0xCC, as GDB *knows* it is doing a infcall, and so knows it can safely insert a 0xCC. (Valgrind gdbsrv needs in any case the Z0 packet, as this is what will ensure the 0xCC is not executed). Not too sure if the above explanations are clear, it is somewhat tricky. 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. Philippe