From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18694 invoked by alias); 20 May 2014 06:40:24 -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 18680 invoked by uid 89); 20 May 2014 06:40:23 -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: mga11.intel.com Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 May 2014 06:40:22 +0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 19 May 2014 23:40:20 -0700 X-ExtLoop1: 1 Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by fmsmga002.fm.intel.com with ESMTP; 19 May 2014 23:40:14 -0700 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.98]) by IRSMSX103.ger.corp.intel.com ([163.33.3.157]) with mapi id 14.03.0123.003; Tue, 20 May 2014 07:40:14 +0100 From: "Metzger, Markus T" To: Pedro Alves CC: "gdb-patches@sourceware.org" Subject: RE: [PATCH] btrace, vdso: add vdso target sections Date: Tue, 20 May 2014 06:40:00 -0000 Message-ID: References: <1396601586-24380-1-git-send-email-markus.t.metzger@intel.com> <53760BDF.2080500@redhat.com> <537A7A80.3050801@redhat.com> In-Reply-To: <537A7A80.3050801@redhat.com> 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/msg00402.txt.bz2 > -----Original Message----- > From: Pedro Alves [mailto:palves@redhat.com] > Sent: Monday, May 19, 2014 11:41 PM > To: Metzger, Markus T > Even in absence of section information, the cache should still be able to > handle the case of the target returning TARGET_XFER_UNAVAILABLE or > TARGET_XFER_E_IO or any error for memory that is outside the region > that the original caller of the memory read routine asked for. > Looks like that fallback is missing. >=20 > Does this patch fix it ? It does when we request TARGET_OBJECT_MEMORY. Thanks, Markus. > On 05/19/2014 12:30 PM, Metzger, Markus T wrote: > >> -----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. >=20 > I got a bit confused by the above sentence. You must mean, a > function in target.c (target_read, etc.), not the target's > read memory function. >=20 > > 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? >=20 > Even in absence of section information, the cache should still be able to > handle the case of the target returning TARGET_XFER_UNAVAILABLE or > TARGET_XFER_E_IO or any error for memory that is outside the region > that the original caller of the memory read routine asked for. > Looks like that fallback is missing. >=20 > Does this patch fix it ? >=20 > --- >=20 > gdb/dcache.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) >=20 > diff --git a/gdb/dcache.c b/gdb/dcache.c > index d3b546b..e75f583 100644 > --- a/gdb/dcache.c > +++ b/gdb/dcache.c > @@ -497,8 +497,11 @@ dcache_read_memory_partial (struct target_ops > *ops, DCACHE *dcache, >=20 > if (i =3D=3D 0) > { > - /* FIXME: We lose the real error status. */ > - return TARGET_XFER_E_IO; > + /* Even though reading the whole line failed, we may be able to > + read a piece starting where the caller wanted. */ > + return ops->to_xfer_partial (ops, TARGET_OBJECT_RAW_MEMORY, > NULL, > + myaddr, NULL, memaddr, len, > + xfered_len); > } > else > { 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