GNU Arm Embedded Toolchain

Processing behavior of .gnu.sgstubs in linker script

Asked by Dennis Wong

When we use the arm-none-eabi tool chain to develop Cortex-M33, we encountered the following questions, please help us to answer them.
1. Since b.w has a limited jump range, is there a range for NSC to jump to Secure code? Their jump range is plus or minus 16MB, right?
2. When using the NSC function, the linker will generate a special .gnu.sgstubs Output Section. But we found through experiments that the section size calculated by recording the VMA at the beginning and end of the Output Section is different from the Seciton Size calculated outside the Output Section using the SIZEOF function built in the linker script! Why does this happen? Are there any side effects of using SIZEOF to calculate?

Thank you for your kind reply and help.

The version of the toolchain we use is "arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]".
The version of the server is "3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux".

Question information

Language:
English Edit question
Status:
Solved
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Solved by:
Dennis Wong
Solved:
Last query:
Last reply:
Revision history for this message
Dennis Wong (binencoder) said : 		#1

  I’m very sorry, but I can only describe the problem in words.
  The linker script code in question is as follows.

    .gnu.sgstubs : ALIGN(32)
    {
        _sg_veneer_code_start = .;
        KEEP(*(.gnu.sgstubs.*))
        . = ALIGN(32);
        _sg_veneer_code_end = .;
    } > TCM_NSC AT > ROM_SECURE
      _gnu_sgstubs_load = LOADADDR(.gnu.sgstubs);

    _gnu_sgstubs_start = ADDR(.gnu.sgstubs);
    _gnu_sgstubs_end = ADDR(.gnu.sgstubs) + SIZEOF(.gnu.sgstubs);

  For question 2, add some specific descriptions.
  The symbol _sg_veneer_code_end has a different value from _gnu_sgstubs_end calculated using SIZEOF, which confuses us very much. Is this a bug?

Revision history for this message
Dennis Wong (binencoder) said : 		#2
Revision history for this message
Daniel Oliveira (raz3l) said : 		#3

I'm also experiencing something similar, but in my case my to variables to get the size from the .gnu.stubs output section are pointing to the same address, while I can see code in the listing file. If I'm not missing anything, this seems to me a strange behavior.

linkerscrip:
    .gnu.sgstubs :
    {
        __sg_start = .;

        KEEP(*(.gnu.sgstubs.*));
        . = ALIGN(32);
        __sg_end = .;

    } > CTCM AT>FLASH

lst:

300054c0 g .gnu.sgstubs 00000000 __sg_start
300054c0 g .gnu.sgstubs 00000000 __sg_end
 ...
Disassembly of section .gnu.sgstubs:

300054c0 <sg_write_reg>:
300054c0: e97f e97f sg
300054c4: f7ff bf97 b.w 300053f6 <__acle_se_sg_write_reg>

300054c8 <sg_read_reg>:
300054c8: e97f e97f sg
300054cc: f7ff bf50 b.w 30005370 <__acle_se_sg_read_reg>
 ...

Revision history for this message
Dennis Wong (binencoder) said : 		#4

Hi Daniel,
  Yes, I can also see the generated secure gateway veneer code in the disassembly file, but there is a problem with the symbol address in .gnu.sgstubs, so there is no way to move the data to the TCM.
  Fortunately, the correct address can be obtained through the built-in function of SIZEOF.

Revision history for this message
Daniel Oliveira (raz3l) said : 		#5

That's the workaround that I also used to move my code to a TCM.

Revision history for this message
Dennis Wong (binencoder) said : 		#6

The linker seems to have a bug, but it can be solved temporarily with SIZEOF.