Message ID | 537A7A80.3050801@redhat.com |
---|---|
State | Not applicable |
Headers |
Return-Path: <x14314964@homiemail-mx21.g.dreamhost.com> X-Original-To: siddhesh@wilcox.dreamhost.com Delivered-To: siddhesh@wilcox.dreamhost.com Received: from homiemail-mx21.g.dreamhost.com (peon2454.g.dreamhost.com [208.113.200.127]) by wilcox.dreamhost.com (Postfix) with ESMTP id B0E4A360098 for <siddhesh@wilcox.dreamhost.com>; Mon, 19 May 2014 14:41:37 -0700 (PDT) Received: by homiemail-mx21.g.dreamhost.com (Postfix, from userid 14314964) id 6504B2772BEF; Mon, 19 May 2014 14:41:37 -0700 (PDT) X-Original-To: gdb@patchwork.siddhesh.in Delivered-To: x14314964@homiemail-mx21.g.dreamhost.com Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by homiemail-mx21.g.dreamhost.com (Postfix) with ESMTPS id 2032D2780956 for <gdb@patchwork.siddhesh.in>; Mon, 19 May 2014 14:41:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=UgNxKQORDa1GUXtw MYJ9krDGwTh0q6ePaj1SNhJM3iwPYJtZM+19fpOOgz96LekHSjPBSNLAQrdTlT3+ EQHdnAr+YLDwLiNdPRl1wexZuJqsEWD7JdWBix2C/xl02BbA9A8mFKlgrUM0E6zf 9zn1UL8V3lkz8xmg8PE1TxK5BoE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=default; bh=4ny31BK9+vQNs4dtgrZ0kJ qVQZU=; b=Qvql0uSOYJ9mY2v3jpSltTRxeB+2ZUbqtPNW0Ls+owitkW5epl3TI5 Q/0xO7pwO91CR5sj9/90ZuA2HkCz+U0irt21F22RdEtFHdApMHbKx1s6GSEipX15 cfkMIwa6InTbCS8YMfDozH7lAG3/kOn9U/ks0Y0dqDI08x8QrMZWU= Received: (qmail 1048 invoked by alias); 19 May 2014 21:41:35 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-gdb=patchwork.siddhesh.in@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 1037 invoked by uid 89); 19 May 2014 21:41:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 May 2014 21:41:33 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4JLfOGK005092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 May 2014 17:41:25 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s4JLfKtN005516; Mon, 19 May 2014 17:41:22 -0400 Message-ID: <537A7A80.3050801@redhat.com> Date: Mon, 19 May 2014 22:41:20 +0100 From: Pedro Alves <palves@redhat.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Metzger, Markus T" <markus.t.metzger@intel.com> CC: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org> Subject: Re: [PATCH] btrace, vdso: add vdso target sections References: <1396601586-24380-1-git-send-email-markus.t.metzger@intel.com> <53760BDF.2080500@redhat.com> <A78C989F6D9628469189715575E55B230C16E478@IRSMSX104.ger.corp.intel.com> <A78C989F6D9628469189715575E55B230C16E5C6@IRSMSX104.ger.corp.intel.com> In-Reply-To: <A78C989F6D9628469189715575E55B230C16E5C6@IRSMSX104.ger.corp.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-DH-Original-To: gdb@patchwork.siddhesh.in |
Commit Message
Pedro Alves
May 19, 2014, 9:41 p.m. UTC
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. 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. > 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? 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. Does this patch fix it ? --- gdb/dcache.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
Comments
> -----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. > > 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. > > 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. > > > 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? > > 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. > > Does this patch fix it ? > > --- > > gdb/dcache.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > 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, > > if (i == 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
On 05/20/2014 07:40 AM, Metzger, Markus T wrote: >> Does this patch fix it ? > > It does when we request TARGET_OBJECT_MEMORY. You mean, the patch should have been: - return ops->to_xfer_partial (ops, TARGET_OBJECT_RAW_MEMORY, + return ops->to_xfer_partial (ops, TARGET_OBJECT_MEMORY, ?
> -----Original Message----- > From: Pedro Alves [mailto:palves@redhat.com] > Sent: Tuesday, May 20, 2014 1:12 PM > To: Metzger, Markus T > Cc: gdb-patches@sourceware.org > Subject: Re: [PATCH] btrace, vdso: add vdso target sections > > On 05/20/2014 07:40 AM, Metzger, Markus T wrote: > > >> Does this patch fix it ? > > > > It does when we request TARGET_OBJECT_MEMORY. > > You mean, the patch should have been: > > - return ops->to_xfer_partial (ops, TARGET_OBJECT_RAW_MEMORY, > + return ops->to_xfer_partial (ops, TARGET_OBJECT_MEMORY, > > ? Yes. 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
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, if (i == 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 {