GCC Bugzilla Bug 29721

The libjava testsuite gets a FAIL in the gij PR12350 test.  I traced this to a
SIGBUS in a yet to be determined location in verify.cc.  When verify.cc is
compiled with -O0 the test PASSes.

This is with the svn trunk -r118192.  I am fairly certain that the same problem
exists in the 4.2 branch as I am getting the same FAILures there, but have not
investigated in detail.

I know this is kind of vague.  I will try to get a proper reduced testcase
soon. Unfortunately the failure mode is such that it is impossible to get a
backtrace at the point of the SIGBUS.  The PC is getting set to a point in
unmapped memory evidently after doing a 'jr v1' which is kind of a wierd thing
to be doing.

I guess I should note that i686 does not seem suffer from this bug.

It looks like the problem here is that a %lo relocation is getting seperated
from its corresponding %got.  Here is a little of the assembly, note how there
is an intervening %got/%lo between the %got($L2406) and the %lo($L2406):

        .loc 1 1634 0
        addiu   $3,$3,-4
$LVL1875:
        sltu    $2,$3,8
        .set    noreorder
        .set    nomacro
        bne     $2,$0,$L3018
        lw      $4,%got($L2406)($28)
        .set    macro
        .set    reorder

        .loc 1 1671 0
        lw      $5,%got($LC29)($28)
        move    $4,$22
        addiu   $5,$5,%lo($LC29)
        lw      $25,%call16(_ZN20_Jv_BytecodeVerifier11verify_failEPKci)($28)
$LEHB200:
        .set    noreorder
        .set    nomacro
        jalr    $25
        li      $6,-1                   # 0xffffffffffffffff
        .set    macro
        .set    reorder

$LVL1876:
$L2392:
$LBE9309:
$LBE9307:
$LBE9305:
$LBB9318:
$LBB9304:
        .loc 1 693 0
        li      $3,10                   # 0xa
$LVL1877:
        .set    noreorder
        .set    nomacro
        b       $L2396
        move    $16,$0
        .set    macro
        .set    reorder

$LVL1878:
$L3018:
$LBE9304:
$LBE9318:
$LBB9319:
$LBB9306:
$LBB9308:
        .loc 1 1634 0
        sll     $2,$3,2
        addiu   $4,$4,%lo($L2406)
        addu    $2,$2,$4
        lw      $3,0($2)
        addu    $3,$3,$28
        j       $3
        .section       
.rodata._ZN20_Jv_BytecodeVerifier21verify_instructions_\
0Ev,"aG",@progbits,_ZN20_Jv_BytecodeVerifier21verify_instructions_0Ev,comdat
        .align  2
        .align  2
$L2406:
        .gpword $L2398
        .gpword $L2399
        .gpword $L2400
        .gpword $L2401
        .gpword $L2402
        .gpword $L2403
        .gpword $L2404
        .gpword $L2405

Manually moving the

   lw      $4,%got($L2406)($28)

to be just before the

   addiu   $4,$4,%lo($L2406)

and reassembling fixes the problem.

So I think that my analysis about the problem being splitting them up with
another %got() relocation between is correct.

Now the question is how to fix it.

OK, looks like GCC may be allowed to emit the relocations out of order.  I am
looking into the possiblility that gas can be fixed so that the relocaitons are
emitted in the proper order even if their position in the code is out of order.

This is a gas bug.

This is probably the fix:

http://sourceware.org/ml/binutils/2006-11/msg00055.html