[Bug gas/12532] New: arm: gas may assemble b to locally-defined, preemptible global symbol as "b.n"

[dave.martin at linaro dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=12532

           Summary: arm: gas may assemble b to locally-defined,
                    preemptible global symbol as "b.n"
           Product: binutils
           Version: 2.22 (HEAD)
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gas
        AssignedTo: address@hidden
        ReportedBy: address@hidden


Created attachment 5270
  --> http://sourceware.org/bugzilla/attachment.cgi?id=5270
Compiler output demonstrating the problem

Gas sometimes emits a short branch and an R_ARM_THUMB_JUMP11 relocation for an
unqualified branch ("b") to a global symbol defined in the same source file.

However, there's no guarantee that R_ARM_THM_JUMP11 relocation can be resolved
correctly if the symbol gets preempted.

Observed in binutils-arm-linux-gnueabi 2.20.51.20100908-0ubuntu2cross1.52.
Observed on binutils trunk on 2011-02-25.

The problem seems to strike in practice when the compiler optimises a sibling
call to "b <label>", for which the assembler generates a b.n.  Handed-coded
assembler can also cause the same problem.

As a side-effect of the presence of this relocation, Thumb-2 kernel modules may
fail to load, since the kernel doesn't support fixing up this relocation. I
believe the kernel doesn't do any symbol preemption processing when loading
modules -- if so, the relocation is actually redundant. But there's no way for
the kernel to detect at module load time that the relocation can safely be
ignored. In kernel builds, about 1 out every 6 modules suffers from this
problem. It's not clear to me whether the method used by the kernel to link .ko
objects is wrong or not.

It seems that either the tools should support symbol preemption in this
scenario (implying that a short branch is not adequate to guarantee that
preemption will work -- i.e., a gas bug) or not (in this case the fixup should
be done locally and there should presumably be no relocation -- i.e., a
different gas bug).

It appears that passing -fno-optimize-sibling-calls to GCC can work around the
problem by avoiding the generation of local branches to global symbols, but
this is clearly not the correct long-term fix.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.