Comment 20 for bug 1697255

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
>