TZ: wrong veneer code is generated for __gnu_cmse_nonsecure_call when code is too far off

[Hans Gfirtner]

Hi,
I encountered an issue with arm-none-eabi-gcc related to trustzone on M33 build.

(on gcc-arm-none-eabi-10.3-2021.10 as well as on latest arm-gnu-toolchain-12.2.mpacbti-bet1-x86_64-arm-none-eabi)

My code is compiled for thumb2 with -mthumb and -mcmse.
When the non-secure function, which I call from secure code is too far away,
I observe that the linker generates veneer code which seems to be ARM code not THUMB code.
This caused my system to crash with a UsageFault.
Generated code from Compiler/linker for those long calls is for example:

1001d090: f002 eec6 blx 1001fe20 <____gnu_cmse_nonsecure_call_veneer>

that is ARM code not THUMB2 code and caused the crash.
when I place the code closer together I do get:

180447ca: f7ff ff45 bl 18044658 <__gnu_cmse_nonsecure_call>

that is proper THUMB2 code as expected.
BR
Hans

[SRINATH PARVATHANENI (sripar01)]

Hi,

Could you please provide a reproducer for the mentioned issue.

Regards,
Srinath.

[Hans Gfirtner (hgfirtne)]

to reproduce:
make a secure -> non-secure call like:

typedef int __attribute__((cmse_nonsecure_call)) non_sec_func(void);
e.g:
 non_sec_func *non_sec_reset;
 uint32_t *vt_ns;

 vt_ns = (uint32_t *)SCB_NS->VTOR;
 __TZ_set_MSP_NS(vt_ns[0]);
 non_sec_reset = (non_sec_func *)(vt_ns[1]);
 non_sec_reset();
placed in memory with a big offset to the entry function (vt_ns[1]) (in my case it was off by 0x08000000)
with proper SAU_config etc. any initial secure -> non secure example shall be ok
please don't forget to compile with -mthumb!
I hope thats enough information to reproduce this issue, if not please let me know in detail what else you need,
BR
Hans

[SRINATH PARVATHANENI (sripar01)]

Sorry, that information is not helpful, could you please provide a reproducer as mentioned here (https://gcc.gnu.org/bugs/) with a proper testcase and complete set of command line options passed and the complete error message.

Regards,
SRI.

[Hans Gfirtner (hgfirtne)]

ok understood,
I isolated the issue with a small main.c and linker script scatter.ld.

gcc version:
arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10.3-2021.10) 10.3.1 20210824 (release)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

compile command:
arm-none-eabi-gcc -mcpu=cortex-m33 --specs=nosys.specs -Wl,--gc-sections -static --specs=nano.specs -mfpu=fpv5-sp-d16 -mfloat-abi=hard --save-temps -mthumb -mcmse -O2 -Wl,--cmse-implib main.c -T scatter.ld

create disassably:
arm-none-eabi-objdump -D a.out >a.dis

wrong gcc code generated:
in a.dis:
10000052: f000 e806 blx 10000060 <____gnu_cmse_nonsecure_call_veneer>
!This is ARM code not THUMB2 code as expected from -mthumb!

not relevant for the issue, but correct code can be generated, when scatter.ld line 14 is changed from:
  CODE2 (rxw) : ORIGIN = 0x11800000, LENGTH = 512K
to
  CODE2 (rxw) : ORIGIN = 0x11000000, LENGTH = 512K
the gcc does not generate a veneer code since the distance is less than 16MB I guess, then the issue is not seen

[Hans Gfirtner (hgfirtne)]

any news on that? is the information sufficient to reproduce the issue now?