From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16437 invoked by alias); 19 May 2014 11:30:38 -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 16426 invoked by uid 89); 19 May 2014 11:30:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mga01.intel.com Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 May 2014 11:30:36 +0000 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 19 May 2014 04:30:35 -0700 X-ExtLoop1: 1 Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by fmsmga001.fm.intel.com with ESMTP; 19 May 2014 04:30:33 -0700 Received: from irsmsx151.ger.corp.intel.com (163.33.192.59) by IRSMSX104.ger.corp.intel.com (163.33.3.159) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 19 May 2014 12:30:32 +0100 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.98]) by IRSMSX151.ger.corp.intel.com ([163.33.192.59]) with mapi id 14.03.0123.003; Mon, 19 May 2014 12:30:32 +0100 From: "Metzger, Markus T" To: Pedro Alves CC: "gdb-patches@sourceware.org" Subject: RE: [PATCH] btrace, vdso: add vdso target sections Date: Mon, 19 May 2014 11:30:00 -0000 Message-ID: References: <1396601586-24380-1-git-send-email-markus.t.metzger@intel.com> <53760BDF.2080500@redhat.com> In-Reply-To: Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00336.txt.bz2 > -----Original Message----- > From: Metzger, Markus T > Sent: Monday, May 19, 2014 10:06 AM > > > +# trace the test code > > > +gdb_test_no_output "record btrace" > > > +gdb_test "next" > > > > Please add a pattern that makes sure the "next" actually > > finished successfully. There's another problem that showed when I added such a pattern for the "reverse-stepi" command. The command prints "Cannot access memory at address 0x4004b0". The error occurs during frame unwind when we try to disassemble an instruction in order to get its length. The problem is that the GDB memory cache may turn reads from one section into reads from a different section or from memory regions outside of any section. The address, 0x4004b0 is the first entry in .plt, a read-only code section. The disassembler tries to read 1 byte from this address. The memory cache turns this into a request for 64 bytes from 0x400480, which lies in a different section, .rela.plt in my case. The read still succeeds in my example since the other section is also readonly, but there's no guarantee for this. The memory read passes through record_btrace_xfer_partial which reduces the length to fit into a single section, so the target's read memory function tries to read the remainder of the cache line. This eventually fails since the cache line contains a memory region that is not contained in any section and record_btrace_xfer_partial returns TARGET_XFER_UNAVAILABLE. I would argue that the memory cache should not extend the original read request beyond section boundaries. What do you think? 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