Message ID | 20180421214721.7232-2-tom@tromey.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 75156 invoked by alias); 21 Apr 2018 21:47:29 -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-##L=##H@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 74998 invoked by uid 89); 21 Apr 2018 21:47:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.1 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=1001, corresponds, Mask, Properly X-HELO: gateway21.websitewelcome.com Received: from gateway21.websitewelcome.com (HELO gateway21.websitewelcome.com) (192.185.45.212) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 21 Apr 2018 21:47:25 +0000 Received: from cm11.websitewelcome.com (cm11.websitewelcome.com [100.42.49.5]) by gateway21.websitewelcome.com (Postfix) with ESMTP id 92A4F400D0FF4 for <gdb-patches@sourceware.org>; Sat, 21 Apr 2018 16:47:24 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id A0LsflHvXA3CSA0LsfrggM; Sat, 21 Apr 2018 16:47:24 -0500 X-Authority-Reason: nr=8 Received: from 97-122-176-117.hlrn.qwest.net ([97.122.176.117]:51234 helo=bapiya.Home) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from <tom@tromey.com>) id 1fA0Ls-003LQc-Bu; Sat, 21 Apr 2018 16:47:24 -0500 From: Tom Tromey <tom@tromey.com> To: gdb-patches@sourceware.org Cc: Tom Tromey <tom@tromey.com> Subject: [RFA 1/2] Fix decoding of ARM VFP instructions Date: Sat, 21 Apr 2018 15:47:20 -0600 Message-Id: <20180421214721.7232-2-tom@tromey.com> In-Reply-To: <20180421214721.7232-1-tom@tromey.com> References: <20180421214721.7232-1-tom@tromey.com> X-BWhitelist: no X-Source-L: No X-Exim-ID: 1fA0Ls-003LQc-Bu X-Source-Sender: 97-122-176-117.hlrn.qwest.net (bapiya.Home) [97.122.176.117]:51234 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes |
Commit Message
Tom Tromey
April 21, 2018, 9:47 p.m. UTC
-Wduplicated-cond pointed out that arm_record_vfp_data_proc_insn checks "opc1 == 0x0b" twice. I filed this a while ago as PR tdep/20362. Based on the ARM instruction manual at https://www.scss.tcd.ie/~waldroj/3d1/arm_arm.pdf, I think the instruction decoding in this function has two bugs. First, opc1 is computed as: opc1 = bits (arm_insn_r->arm_insn, 20, 23); [...] opc1 = opc1 & 0x04; This means that tests like: else if (opc1 == 0x01) can never be true. In the ARM manual, "opc1" corresponds to these bits: name bit r 20 q 21 D 22 p 23 ... where the D bit is not used for VFP instruction decoding. So, I believe this code should use ~0x04 instead. Second, VDIV is recognized by the bits "pqrs" being equal to "1000". This tranlates to opc1 == 0x08 -- not 0x0b. Note that pqrs==1001 is an undefined encoding, which is probably why opc2 is not checked here; this code doesn't seem to really deal with undefined encodings in general, so I've left that as is. I don't have an ARM machine or any reasonable way to test this. ChangeLog 2018-04-21 Tom Tromey <tom@tromey.com> PR tdep/20362: * arm-tdep.c (arm_record_vfp_data_proc_insn): Properly mask off D bit. Use correct value for VDIV. --- gdb/ChangeLog | 6 ++++++ gdb/arm-tdep.c | 5 +++-- 2 files changed, 9 insertions(+), 2 deletions(-)
Comments
On 22 April 2018 at 02:47, Tom Tromey <tom@tromey.com> wrote: > -Wduplicated-cond pointed out that arm_record_vfp_data_proc_insn > checks "opc1 == 0x0b" twice. I filed this a while ago as > PR tdep/20362. > > Based on the ARM instruction manual at > https://www.scss.tcd.ie/~waldroj/3d1/arm_arm.pdf, I think the > instruction decoding in this function has two bugs. > > First, opc1 is computed as: > > opc1 = bits (arm_insn_r->arm_insn, 20, 23); > [...] > opc1 = opc1 & 0x04; > > This means that tests like: > > else if (opc1 == 0x01) > > can never be true. > > In the ARM manual, "opc1" corresponds to these bits: > > name bit > r 20 > q 21 > D 22 > p 23 > > ... where the D bit is not used for VFP instruction decoding. > > So, I believe this code should use ~0x04 instead. > > Second, VDIV is recognized by the bits "pqrs" being equal to "1000". > This tranlates to opc1 == 0x08 -- not 0x0b. Note that pqrs==1001 is > an undefined encoding, which is probably why opc2 is not checked here; > this code doesn't seem to really deal with undefined encodings in > general, so I've left that as is. > > I don't have an ARM machine or any reasonable way to test this. > > ChangeLog > 2018-04-21 Tom Tromey <tom@tromey.com> > > PR tdep/20362: > * arm-tdep.c (arm_record_vfp_data_proc_insn): Properly mask off D > bit. Use correct value for VDIV. > --- > gdb/ChangeLog | 6 ++++++ > gdb/arm-tdep.c | 5 +++-- > 2 files changed, 9 insertions(+), 2 deletions(-) > > diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c > index f64df4c574..98bbb0244c 100644 > --- a/gdb/arm-tdep.c > +++ b/gdb/arm-tdep.c > @@ -11420,7 +11420,8 @@ arm_record_vfp_data_proc_insn (insn_decode_record *arm_insn_r) > opc3 = bits (arm_insn_r->arm_insn, 6, 7); > dp_op_sz = bit (arm_insn_r->arm_insn, 8); > bit_d = bit (arm_insn_r->arm_insn, 22); > - opc1 = opc1 & 0x04; > + /* Mask off the "D" bit. */ > + opc1 = opc1 & ~0x04; > > /* Handle VMLA, VMLS. */ > if (opc1 == 0x00) > @@ -11485,7 +11486,7 @@ arm_record_vfp_data_proc_insn (insn_decode_record *arm_insn_r) > } > } > /* Handle VDIV. */ > - else if (opc1 == 0x0b) > + else if (opc1 == 0x08) > { > if (dp_op_sz) > curr_insn_type = INSN_T1; > -- > 2.13.6 > Seems LGTM. Let me get back to you after running testsuite for regressions.
>>>>> "Omair" == Omair Javaid <omair.javaid@linaro.org> writes: >> On 22 April 2018 at 02:47, Tom Tromey <tom@tromey.com> wrote: >> -Wduplicated-cond pointed out that arm_record_vfp_data_proc_insn >> checks "opc1 == 0x0b" twice. I filed this a while ago as >> PR tdep/20362. >> >> Based on the ARM instruction manual at >> https://www.scss.tcd.ie/~waldroj/3d1/arm_arm.pdf, I think the >> instruction decoding in this function has two bugs. [...] Omair> Seems LGTM. Let me get back to you after running testsuite for regressions. Did this work out? Tom
On 05/04/2018 06:06 PM, Tom Tromey wrote: >>>>>> "Omair" == Omair Javaid <omair.javaid@linaro.org> writes: > >>> On 22 April 2018 at 02:47, Tom Tromey <tom@tromey.com> wrote: >>> -Wduplicated-cond pointed out that arm_record_vfp_data_proc_insn >>> checks "opc1 == 0x0b" twice. I filed this a while ago as >>> PR tdep/20362. >>> >>> Based on the ARM instruction manual at >>> https://www.scss.tcd.ie/~waldroj/3d1/arm_arm.pdf, I think the >>> instruction decoding in this function has two bugs. > [...] > > Omair> Seems LGTM. Let me get back to you after running testsuite for regressions. > > Did this work out? FAOD, this is OK if there are no regressions. Thanks, Pedro Alves
diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c index f64df4c574..98bbb0244c 100644 --- a/gdb/arm-tdep.c +++ b/gdb/arm-tdep.c @@ -11420,7 +11420,8 @@ arm_record_vfp_data_proc_insn (insn_decode_record *arm_insn_r) opc3 = bits (arm_insn_r->arm_insn, 6, 7); dp_op_sz = bit (arm_insn_r->arm_insn, 8); bit_d = bit (arm_insn_r->arm_insn, 22); - opc1 = opc1 & 0x04; + /* Mask off the "D" bit. */ + opc1 = opc1 & ~0x04; /* Handle VMLA, VMLS. */ if (opc1 == 0x00) @@ -11485,7 +11486,7 @@ arm_record_vfp_data_proc_insn (insn_decode_record *arm_insn_r) } } /* Handle VDIV. */ - else if (opc1 == 0x0b) + else if (opc1 == 0x08) { if (dp_op_sz) curr_insn_type = INSN_T1;