[Qemu-devel] [Bug 1843133] Re: Possibly incorrect branch in qemu-system-hppa

From: "Paulo César Pereira de Andrade" <paulo.cesar.pereira.de.andrade@gmail.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [Bug 1843133] Re: Possibly incorrect branch in qemu-system-hppa
Date: Sat, 07 Sep 2019 16:18:39 -0000	[thread overview]
Message-ID: <156787312020.29497.13569140866903966676.malone@chaenomeles.canonical.com> (raw)
In-Reply-To: 156787148109.29148.9145557698070556446.malonedeb@chaenomeles.canonical.com

As a side note, the branch is correct if testing 0xffffffe + 2
or other combinations to cause a signed overflow. The only
special pattern that fails is '0x7ffffff + 1'.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1843133

Title:
  Possibly incorrect branch in qemu-system-hppa

Status in QEMU:
  New

Bug description:
  I plan to release a new GNU Lightning soon.
  I no longer have access to any physical HPPA, but code that
  was tested some years ago did work on HPPA/HP-UX, and now it
  appears qemu-system-hppa incorrectly branches in code generated
  by GNU Lightning. Currently only 32 bit hppa jit generation
  supported.

  In the lightning check/test tool, the code would be:

  .code
      prolog
      movi %r0 0x7fffffff
      movi %r1 1
      boaddr L0 %r0 %r1
      calli @abort
  L0:
      ret
      epilog

  The code/debug information looks like this:
              movi r4 0x7fffffff
              0xf8ef5018      ldil L%7ffff800,r4
              0xf8ef501c      ldo 7ff(r4),r4
              movi r5 0x1
              0xf8ef5020      ldi 1,r5
          boaddr L1 r4 r5
              0xf8ef5024      addb,sv,n r5,r4,0xf8ef5044 :a.tst:291
              0xf8ef5028      nop
          calli 0xf8eeb68a
              [...]
      L1:

  Apparently it is not understanding 0x7fffffff + 1 is a signed
  overflow.

  Tested in Fedora with qemu-system-hppa-3.1.1-2.fc30.x86_64 and using
  the debian-10 image.

  To make it a bit easier to test (partially transformed the
  not so optimized code generated by lightning to gcc -S output):
  # cat a.s
  	.LEVEL 1.1
  	.text
  	.align 4
  .globl main
  	.type	main, @function
  main:
  	.PROC
  	.CALLINFO FRAME=64,NO_CALLS,SAVE_SP,ENTRY_GR=3
  	.ENTRY
  	copy %r3,%r1
  	copy %r30,%r3
  	stwm %r1,64(%r30)
  	zdepi -1,31,31,%r23
  	ldi 1,%r24
  	addb,sv,n %r24,%r23,.L0
  	nop
  	ldi 1,%r28
  	b,n .L1
  	nop
  .L0:
  	ldi 0,%r28
  .L1:
  	ldo 64(%r3),%r30
  	ldwm -64(%r30),%r3
  	bv,n %r0(%r2)
  	.EXIT
  	.PROCEND
  	.size	main, .-main

  # gcc a.s
  # ./a.out; echo $?
  1

  It should have returned 0.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1843133/+subscriptions