This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
pending/1021: [RFA] sim/h8300/h8300.c: Fix the handling of bxor.
- From: Kazu Hirata <kazu at cs dot umass dot edu>
- To: gdb-gnats at sources dot redhat dot com
- Date: Wed, 08 Jan 2003 12:56:15 -0500 (EST)
- Subject: pending/1021: [RFA] sim/h8300/h8300.c: Fix the handling of bxor.
>Number: 1021
>Category: pending
>Synopsis: [RFA] sim/h8300/h8300.c: Fix the handling of bxor.
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: change-request
>Submitter-Id: unknown
>Arrival-Date: Sun Feb 02 06:48:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:
>Release:
>Organization:
>Environment:
>Description:
Hi,
Attached is a patch to fix the handling of bxor.
Without the patch, running h8300-hms-run on
mov.w #0x80,r0l
bld #7,r0l
bxor #7,r0l
bst #0,r0l
results in r0l equal to 0x81, whereas the correct simulation should
give 0x80. This is because bxor is mishandled. Specifically, "C"
below is a macro that takes a value of either 0 or 1. "ea & m" takes
0 or m depending on the bit position, so comparing these two does not
mean XOR. Instead, we should force "ea & m" to take a value of 0 or 1
by saying "!!(ea & m)".
OK to apply?
Kazu Hirata
2003-01-08 Kazu Hirata <kazu@cs.umass.edu>
* compile.c (sim_resume): Fix the handling of bxor.
Index: compile.c
===================================================================
RCS file: /cvs/src/src/sim/h8300/compile.c,v
retrieving revision 1.18
diff -u -r1.18 compile.c
--- compile.c 26 Dec 2002 05:44:46 -0000 1.18
+++ compile.c 8 Jan 2003 17:30:45 -0000
@@ -1521,7 +1521,7 @@
OBITOP (O_BIAND, 1, 0, c = !(ea & m) && C);
OBITOP (O_BOR, 1, 0, c = (ea & m) || C);
OBITOP (O_BIOR, 1, 0, c = !(ea & m) || C);
- OBITOP (O_BXOR, 1, 0, c = (ea & m) != C);
+ OBITOP (O_BXOR, 1, 0, c = !!(ea & m) != C);
OBITOP (O_BIXOR, 1, 0, c = !(ea & m) != C);
#define MOP(bsize, signed) \
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: