From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16979 invoked by alias); 18 Dec 2013 09:26:28 -0000 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 Received: (qmail 16969 invoked by uid 89); 18 Dec 2013 09:26:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mga02.intel.com Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Dec 2013 09:26:26 +0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 18 Dec 2013 01:26:24 -0800 X-ExtLoop1: 1 Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga002.jf.intel.com with ESMTP; 18 Dec 2013 01:25:35 -0800 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.135]) by IRSMSX101.ger.corp.intel.com ([163.33.3.153]) with mapi id 14.03.0123.003; Wed, 18 Dec 2013 09:24:14 +0000 From: "Metzger, Markus T" To: Pedro Alves CC: "jan.kratochvil@redhat.com" , "gdb-patches@sourceware.org" Subject: RE: [patch v8 17/24] record-btrace: provide xfer_partial target method Date: Wed, 18 Dec 2013 09:26:00 -0000 Message-ID: References: <1386839747-8860-1-git-send-email-markus.t.metzger@intel.com> <1386839747-8860-18-git-send-email-markus.t.metzger@intel.com> <52AB555A.3070301@redhat.com> <52AF5188.9040800@redhat.com> <52B08240.7060400@redhat.com> In-Reply-To: <52B08240.7060400@redhat.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00688.txt.bz2 > -----Original Message----- > From: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] On Behalf Of Pedro Alves > > I have something to temporarily disable the xfer checks during > > to_insert_breakpoint and to_remove_breakpoint. > > > > Not sure whether this is considered too hacky or what else I'm missing. >=20 > It's hacky as the breakpoints in memory will never actually > trigger/execute. If you want to assume that the inferior's current > read only sections match exactly the read only sections the program > had when the trace was taken, I won't insist. The assumption will > fail across tracing e.g., dlopen/dlclose/mmap/unmmap, as breakpoints > will fail to insert on unmapped sections. Right. I might as well just ignore insert and remove breakpoints. When I do that, however, I might leak breakpoint instructions for breakpoints that have been deleted while replaying. Or I might end up with breakpoints that have not been properly inserted. The easiest choice seems to be to actually insert and remove breakpoint instructions into the target memory. This will fail if the current process image does not match the process image at the time of the recorded execution. This is currently not supported and will fail for various other reasons, as well. For one, I won't be able to disassemble instructions that are no longer there or might have been replaced meanwhile. Regards, Markus. Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052