This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [patch] gas/config/tc-h8300.c (build_bytes): Assemble ldmac correctly.


  In message <200006242323.QAA05447@cygnus.com>you write:
  > Hi,
  > 
  > Attached is a patch to fix a bug in h8300-hms-as. The original gas
  > does not assemble the first two lines of the following function
  > correctly. The last two lines are OK.
  > 
  > /* h8300-hms-gcc -ms -Wall -O2 -fomit-frame-pointer */
  > void
  > test ()
  > {
  >   __asm__ __volatile__ ("ldmac\ter4,mach");
  >   __asm__ __volatile__ ("ldmac\ter5,macl");
  >   __asm__ __volatile__ ("stmac\tmach,er4");
  >   __asm__ __volatile__ ("stmac\tmacl,er5");
  > }
  > 
  > Without the patch,
  > 
  > 00000000 <_test>:
  >    0:	03 64       	03 64             ldmac	er4,mach <- incorrect
  >    2:	03 75       	03 75             ldmac	er5,mach <- incorrect
  >    4:	02 24       	02 24             stmac	mach,er4
  >    6:	02 35       	02 35             stmac	macl,er5
  >    8:	54 70       	54 70             rts	
  > 
  > With the patch, 
  > 
  > 00000000 <_test>:
  >    0:	03 24       	03 24             ldmac	er4,mach <- correct
  >    2:	03 35       	03 35             ldmac	er5,macl <- correct
  >    4:	02 24       	02 24             stmac	mach,er4
  >    6:	02 35       	02 35             stmac	macl,er5
  >    8:	54 70       	54 70             rts	
  > 
  > The problem is that the variable 'd' in 'build_bytes ()' is always 0,
  > meaning the first operand, when processing MACREG. However, as you can
  > see from the assembly code, when we want to know which half of the mac
  > register (mach or macl) is used, we have to look at either the first
  > or second operand depending on ldmac or stmac.
  > 
  > By the way, the existing testsuite (gas/testsuite/gas/h8300/h8300.exp
  > and macs.s) is correct. The reason this bug got away with a failure is
  > a coincident that you would never expect. If you change the 32-bit
  > registers (er0 and er1) used in macs.s to some other 32-bit registers
  > (say, er4 and er5 just like the above example) and change h8300.exp
  > accordingly, the original gas would fail.
Can you please install a test for this bug into the testsuite?

I believe Nick C. already approved the tc-h8300.c change.
Thanks,
jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]