Home Original page

Long call support broke Thumb veneers

Daniel Jacobowitz drow@false.org
Tue Jun 3 13:55:00 GMT 2008 
The last good -mthumb test run our autotester had for arm-none-eabi
was on 2008-05-14.  Every run since has failed thoroughly enough that
the test results bounced from gcc-testresults (over 400k).

I've tracked the problem down to a call (this example is
gcc.c-torture/execute/va-arg-12.c, which happened to be running when I
checked the progress):

0x00008178 <f+0>:       push    {r4, r5, r6, lr}
0x0000817a <f+2>:       mov     r3, sp
0x0000817c <f+4>:       adds    r3, #79
0x0000817e <f+6>:       adds    r4, r3, #0
0x00008180 <f+8>:       movs    r5, #7
0x00008182 <f+10>:      bics    r4, r5
0x00008184 <f+12>:      ldr     r0, [r4, #0]
0x00008186 <f+14>:      ldr     r1, [r4, #4]
0x00008188 <f+16>:      ldr     r3, [pc, #72]   (0x81d4 <f+92>)
0x0000818a <f+18>:      ldr     r2, [pc, #68]   (0x81d0 <f+88>)
0x0000818c <f+20>:      bl      0x85f8 <__aeabi_dcmpeq>

0x000085f8 <__aeabi_dcmpeq+0>:  str     lr, [sp, #-8]!
0x000085fc <__aeabi_dcmpeq+4>:  bl      0x85e0 <__aeabi_cdcmple>
0x00008600 <__aeabi_dcmpeq+8>:  moveq   r0, #1  ; 0x1
0x00008604 <__aeabi_dcmpeq+12>: movne   r0, #0  ; 0x0
0x00008608 <__aeabi_dcmpeq+16>: ldr     lr, [sp], #8
0x0000860c <__aeabi_dcmpeq+20>: bx      lr

arm-none-eabi-gcc -mthumb defaults to ARM v4-T.  The call should have
gone to a glue routine to convert to Thumb mode.  This is a problem
Paul spotted on the original patch :-(

Christophe, you removed handling of two relocation types from
bfd_elf32_arm_process_before_allocation, which is responsible for
inserting these stubs.  How do you intend they be handled?
record_arm_to_thumb_glue is now never called for them.

In general, handling long call stubs differently from mode-changing
stubs seems like asking for trouble.

-- 
Daniel Jacobowitz
CodeSourcery
More information about the Binutils mailing list