https://bugs.kde.org/show_bug.cgi?id=417281

--- Comment #5 from Julian Seward <jsew...@acm.org> ---
(In reply to Julian Seward from comment #4)
> As a next step I am inclined to add printf lines for all cases (rules)
> in the insn selector.  Then run the test case with and without &&-recovery
> enabled, so as to find the sets of rules used in both cases, and diff
> them, to see what is only used when &&-recovery is enabled.  Then look
> more closely at those cases.

I did that yesterday.  The only rules I found like that were for Iop_And1 
and Iop_Or1, as expected.  And these still look correct to me.  So I really
don't think this is an instruction selector problem, and for reasons explained
in comment #4, I don't think this is a front end problem either.  That leaves
as possibilities either the register allocator (core logic), the s390-specific
support for the register allocator (getRegUsage_S390, basically), or something
to do with the stack layout.

I experimented with register allocation a bit.  getRRegUniverse_S390() tells
the register allocator which registers are available.  If register allocation
is correct, removing some registers from the set of available ones should not
change the behaviour of the code, affecting only performance.  But it does
make a difference.  getRRegUniverse_S390() provides GPRs in two separate
groups: 1..5 and 6..11.  Removing one group or the other does not change the
place (in the guest code) where V crashes, but it does change the error
messages at the crash point.  This seems like a big red flag to me.

With the GPR group 6..11 removed from allocation, what I notice is that the
crash occurs soon after a call to a helper function.  And it crashes due to
an invalid memory reference, using as address, a value which is spilled 
before the call and reloaded afterwards.  I'll put a longer disassembly in
an attached file, but here are the essentials:

   // r13 is the guest state pointer.  It points to an area which
   // is: 3 copies of struct VexGuestS390XState, followed by a spill area.
   0x0000001003c5be5a:  llilf   %r0,67149062 ; 0x4009d06
   0x0000001003c5be60:  stg     %r0,720(%r13) ; set guest PC to 0x4009d06

   // Do stuff (I don't know what; probably not important)
   0x0000001003c5be66:  lg      %r5,656(%r13)
   0x0000001003c5be6c:  sllg    %r5,%r5,3
   0x0000001003c5be72:  ag      %r5,624(%r13)
   0x0000001003c5be78:  lg      %r4,1472(%r13)
   0x0000001003c5be7e:  sllg    %r4,%r4,3
   0x0000001003c5be84:  og      %r4,1440(%r13)
   0x0000001003c5be8a:  ltgr    %r4,%r4
   0x0000001003c5be8e:  stg     %r5,2464(%r13) ; spill <---
   0x0000001003c5be94:  je      0x1003c5beae

   // helper call; sequence created by s390_insn_helper_call_emit()
   0x0000001003c5be98:  iihf    %r1,8
   0x0000001003c5be9e:  iilf    %r1,98288
   0x0000001003c5bea4:  stfpc   232(%r15)
   0x0000001003c5bea8:  basr    %r14,%r1
   0x0000001003c5beaa:  lfpc    232(%r15)

   // after the call
   0x0000001003c5beae:  lg      %r5,2464(%r13) ; reload <---
   0x0000001003c5beb4:  lgr     %r2,%r5

   // another helper call
   0x0000001003c5beb8:  iihf    %r1,8
   0x0000001003c5bebe:  iilf    %r1,95000
   0x0000001003c5bec4:  stfpc   232(%r15)
   0x0000001003c5bec8:  basr    %r14,%r1
   0x0000001003c5beca:  lfpc    232(%r15)

   // after the call
   0x0000001003c5bece:  lgr     %r5,%r2
   0x0000001003c5bed2:  lg      %r3,2464(%r13) ; reload <---
=> 0x0000001003c5bed8:  lg      %r4,0(%r3) // crash (r3 is near zero) <---

So it might be that 2464(%r13) got corrupted across one of the helper calls.

>From comments on VexGuestS390XState, it appears that this has size 816 bytes.
If that's correct, then the 3 copies of it starting at 0(%r13) have total size
2448 bytes, so offset 2464 is 16 bytes into the spill area.

So that's my analysis so far.  I think it is suspicious that changing the
available register set changes the messages shown at the failure site.  But
the analysis might be wrong.  For example, it may be the value that is 
computed into %r5 and then spilled into 2464(%r13) is already wrong, and
that the spilling is OK.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to