Hi, sorry for the delay.  I have attached a simple build.  I also noticed I
can create the same issue using addresses that are far, without PIE.

Attached is the zip file.

On Thu, Nov 8, 2018 at 7:00 AM Thomas Preud'homme <email address hidden>
wrote:

> Hi John,
>
> >From what I see this specific veneer should only be generated when
> branching/calling to Arm code *or* when the target supports Arm mode. Ie
> it shouldn't happen for a Thumb-only device. I'd need code and command-
> line option used to reproduce.
>
> Best regards.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1697255
>
> Title:
>   linker switch from thumb to arm mode even cortex m4 doesn't support it
>
> Status in GNU Arm Embedded Toolchain:
>   New
>
> Bug description:
>   gcc version 5.4.1 20160919 (release) [ARM/embedded-5-branch revision
>   240496] (GNU Tools for ARM Embedded Processors)
>
>   We have problems in veneers for functions that is known from a symbol
>   file. Veneers for other functions that exists in the elf file is ok.
>   Maybe only the pie, position independent codes are affected. Let me
>   show an example
>
>   I have an already done elf image let's call it applet.elf and I would
>   like to create an independent binary file let's call it pie.elf that
>   would be a pie, position independent code and it would use some
>   functions from the applet.elf
>
>   first, I compiled applet.elf with -mthumb -mcpu=cortex-m4 -mno-thumb-
>   interwork --just-symbols xprintf.txt
>
>   applet.elf contains printf function and xprintf.txt contains a symbol
>   for xprintf function
>
>   xprintf.txt:
>   xprintf                                  = 0x0809b575 ;
>
>   After this I compile the pie.elf that simple calls the printf and the
>   xprintf functions with the following parameters:
>
>   -fpie -nostdlib -mthumb -mcpu=cortex-m4 -mno-thumb-interwork
>
>   Now let's see the generated code and the problems we have with radare
>   but before this I show something
>
>   arm-none-eabi-objdump -t applet.elf | grep printf
>
>   0809b575 g       *ABS*  00000000 xprintf
>   0809b55c g     F .text  00000028 printf
>
>   I don't know what that zero means at xprintf if I call this function
>   from applet.elf it works well but maybe this info will be useful later
>
>   ok let's see the disassembled code
>
>   0x00000000    80b5         push {r7, lr}
>   0x00000002    00af         add r7, sp, 0
>   0x00000004    054b         ldr r3, [pc, 20]    ; (0x0000001c)
>   0x00000006    7b44         add r3, pc          ; add 0x2e
>   0x00000008    1846         mov r0, r3
>   0x0000000a    00f011f8     bl 0x00000030       ; [1] call printf_veneer
> 0x00000030()
>   0x0000000e    044b         ldr r3, [pc, 16]    ; (0x00000020)
>   0x00000010    7b44         add r3, pc          ; add 0x2c
>   0x00000012    1846         mov r0, r3
>   0x00000014    00f008e8     blx 0x00000028      ;[2] call xprintf_veneer
> 0x00000028()
>   0x00000018    00bf         nop
>   0x0000001a    80bd         pop {r7, pc}
>   0x0000001c    2e00         movs r6, r5
>   0x0000001e    0000         movs r0, r0
>   0x00000020    2c00         movs r4, r5
>   0x00000022    0000         movs r0, r0
>   0x00000024    0000         movs r0, r0
>   0x00000026    0000         movs r0, r0
>   0x00000028    04f01fe5     ; <UNDEFINED> 0xf004e51f ;[3]   0x00004a6a()
>   0x0000002c    75b5         push {r0, r2, r4, r5, r6, lr}
>   0x0000002e    0908         lsrs r1, r1, 32
>   0x00000030    5ff800f0     ldr.w pc, [pc] ; 0x00000034
>   0x00000034    d117         asrs r1, r2, 31
>   0x00000036    0a08         lsrs r2, r1, 32
>
>   0x00000038    7465         str r4, [r6, 84]    ; string: test\n
>   0x0000003a    7374         strb r3, [r6, 17]
>   0x0000003c    0a00         movs r2, r1
>   0x0000003e    0000         movs r0, r0
>
>   0x00000040    7465         str r4, [r6, 84]    ; string test2\n
>   0x00000042    7374         strb r3, [r6, 17]
>   0x00000044    320a         lsrs r2, r6, 8
>   0x00000046    0000         movs r0, r0
>
>   As you can see the opcode of xprintf_veneer is wrong. Maybe the linker
>   switch from thumb to arm mode even cortex m4 doesn't support it
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/gcc-arm-embedded/+bug/1697255/+subscriptions
>