[Bug gold/16085] New: gold assumes STT_NOTYPE symbols are not thumb

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16085

            Bug ID: 16085
           Summary: gold assumes STT_NOTYPE symbols are not thumb
           Product: binutils
           Version: 2.25 (HEAD)
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gold
          Assignee: ian at airs dot com
          Reporter: vries at gcc dot gnu.org
                CC: ccoutant at google dot com

Consider this test program (essentially function test_branch from
gdb/testsuite/gdb.arch/arm-disp-step.S, rewritten in C):
...
int
main (void)
{
  /* Gcc prints label 'L1' as '.L2' in assembler.  */
  asm goto ("b .L2; .global .L2;": : : : L1);
 L1:
  return 0;
}
...

We compile it:
...
$ arm-linux-androideabi-gcc test.c -static -mthumb -save-temps -O2
-march=armv7-a
...

Resulting in this test.s:
...
        .syntax unified
        .arch armv7-a
        .fpu softvfp
        .eabi_attribute 20, 1   @ Tag_ABI_FP_denormal
        .eabi_attribute 21, 1   @ Tag_ABI_FP_exceptions
        .eabi_attribute 23, 3   @ Tag_ABI_FP_number_model
        .eabi_attribute 24, 1   @ Tag_ABI_align8_needed
        .eabi_attribute 25, 1   @ Tag_ABI_align8_preserved
        .eabi_attribute 26, 2   @ Tag_ABI_enum_size
        .eabi_attribute 30, 2   @ Tag_ABI_optimization_goals
        .eabi_attribute 34, 1   @ Tag_CPU_unaligned_access
        .eabi_attribute 18, 4   @ Tag_ABI_PCS_wchar_t
        .file   "test.c"
        .section        .text.startup,"ax",%progbits
        .align  2
        .global main
        .thumb
        .thumb_func
        .type   main, %function
main:
        b .L2
        .global .L2
        .thumb
.L2:
        movs    r0, #0  @,
        bx      lr      @
        .size   main, .-main
...


And this test.o:
...
SYMBOL TABLE:
00000000 g     F .text.startup  00000008 main
00000004 g       .text.startup  00000000 .L2

Disassembly of section .text.startup:

00000000 <main>:
   0:   f7ff bffe       b.w     4 <.L2>
                        0: R_ARM_THM_JUMP24     .L2

00000004 <.L2>:
   4:   2000            movs    r0, #0
   6:   4770            bx      lr
...

The first sign of trouble is here, in the dump of the executable:
...
000080c8 <main>:
    80c8:       f00f b902       b.w     172d0 <raise+0x14>

000080cc <.L2>:
    80cc:       2000            movs    r0, #0
    80ce:       4770            bx      lr
...

The branch in main is not to .L2, but to here:
...
   172ce:       0000            movs    r0, r0
-->172d0:       4778            bx      pc
   172d2:       46c0            nop                     ; (mov r8, r8)
   172d4:       c37c            stmia   r3!, {r2, r3, r4, r5, r6}
   172d6:       eaff 4778       ; <UNDEFINED> instruction: 0xeaff4778
... 
The 'bx pc; nop' is a trick to switch to arm mode, and the '.inst 0xeaffc37c'
following that is in fact a branch to .L2, but not shown as such because it's
disassembling in thumb mode.

Since we switch to arm mode, and then jump to thumb code at.L2, the execution
fails.

When doing the final link step using the bfd linker instead, we get:
...
000080e8 <main>:
    80e8:       f000 b800       b.w     80ec <.L2>

000080ec <.L2>:
    80ec:       2000            movs    r0, #0
    80ee:       4770            bx      lr
...

The reason the gold linker introduces the stub, is because it thinks the target
of the jump is in arm mode. That is due to this code in
Target_arm<false>::Relocate::relocate:
...
  else
    {
      // Set thumb bit if symbol:
      // -Has type STT_ARM_TFUNC or
      // -Has type STT_FUNC, is defined and with LSB in value set.
      thumb_bit =
    (((gsym->type() == elfcpp::STT_ARM_TFUNC)
     || (gsym->type() == elfcpp::STT_FUNC
         && !gsym->is_undefined()
         && ((psymval->value(object, 0) & 1) != 0)))
    ? 1
    : 0);
    }
...

The actual type of the symbol is STT_NOTYPE, and this code sets thumb_bit to 0
in such a case.

Knowing the cause of the failure, we can change the source to make the .L2
symbol of function type, which makes the problem go away:
...
  asm goto ("b .L2; .global .L2; .type   .L2, %%function": : : : L1);
...

Now, I'm not sure if the test-case is valid to begin with. But gold should
either:
- handle the STT_NO_TYPE (see in which function the target is, try to determine
thumbness of that function), or
- fail saying it cannot handle this relocation.

-- 
You are receiving this mail because:
You are on the CC list for the bug.