Using symbolfile with cortexM3 results in illegal thumb->ARM32 trampoline

[Geoffrey Hausheer]

I am building code where the program resides in RAM but many functions reside 
in ROM.  Instead of using relocation, the program uses a symbolfile to specify 
function addresses in ROM.  A long-call is needed to access ROM from RAM.

If the compiler uses a long-call, everything works as expected, but if a 
short-call is made, the linker uses a thumb->ARM32 trampoline instead of a 
short-to-long call trampoline.

The cortexM3 architecture does not support ARM32, so the resulting binary is 
invalid.
test.c:
#pragma long_calls
extern void long_func();
#pragma no_long_calls
extern void short_func();

int main()
{
    long_func();
    short_func();
    return 0;
}

symbolfile:
long_func = 0x0801bbb1;
short_func = 0x0800717d;

compile via:
arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -Wall -Wextra -std=gnu99 -Os -c test.c
arm-none-eabi-ld test.o --just-symbols sym

The resulting disassembled code is:
a.out:     file format elf32-littlearm


Disassembly of section .text:

00008000 <main>:
    8000:       b508            push    {r3, lr}
    8002:       4b03            ldr     r3, [pc, #12]   ; (8010 <main+0x10>)
    8004:       4798            blx     r3
    8006:       f000 e808       blx     8018 <__short_func_from_thumb>
    800a:       2000            movs    r0, #0
    800c:       bd08            pop     {r3, pc}
    800e:       bf00            nop
    8010:       0801bbb1        .word   0x0801bbb1
    8014:       00000000        .word   0x00000000

00008018 <__short_func_from_thumb>:
    8018:       e51ff004        ldr     pc, [pc, #-4]   ; 801c 
<__short_func_from_thumb+0x4>
    801c:       0800717d        .word   0x0800717d

As I work-around I found that I can use the following assembly code instead of 
a symbolfile:
        .global long_func
        .type long_func %function
        .equ    long_func, 0x0801bbb1

        .global short_func
        .type short_func %function
        .equ    short_func, 0x0800717d;

Which results in a short-to-long call veneer as expected.  Is this simply a 
case of symbolfiles not being supported with the cortexm3?  Or perhaps there is 
some way of indicating that the functions in the symbolfile are thumb?