How to get the section size and section base address like Image$$BB_MAIN_STACK$$ZI$$Limit in ARM CC?

Hi riptide,

The GNU linker will define symbols __start_BB_MAIN_STACK and __stop_BB_MAIN_STACK if your code references these symbols. Thus you could do:

extern void * __start_BB_MAIN_STACK, __stop_BB_MAIN_STACK;

void
foo (void)
{
  printf ("base: %p\n, __start_BB_MAIN_STACK);
  printf ("size: %p\n, __stop_BB_MAIN_STACK - __start_BB_MAIN_STACK);
}

Note that this only work if the constructed symbol is a valid C identifier. Therefore, if your section is called .bar it will not work since dots are not legal in C identifiers.

Best regards.

Hi, Thomas,
    Thanks for your kindly reply.
    And could you tell me where can I find the information about the _start_xxxx and __stop_xxxx in the GNU documents.

Best Regards.

Hi riptide,

This feature is described in the section about orphan sections: https://sourceware.org/binutils/docs-2.24/ld/Orphan-Sections.html#Orphan-Sections

In case of non orphan sections, either it's a standard one and there is already symbols defined (such as __end__ and the like) or it's a non standard one and it means there should be an entry in the linker script where you could add symbols for the start and end of that section.

Best regards.

Thanks Thomas Preud'homme, that solved my question.

I am sorry for that I have another question.
We can use the code in a c file like below:
__attribute__((section("ModuleInfo")))
FIRMWARE_INFO_T const ModuleInfo =
{

    (uint32)(&Load$$MODULE_INFO$$Base),

    //MODUE_INFO_TABLE
    {
        (uint32)(MAX_MODULE_NUM),
        {
            //SYS SEG
            {
                (uint32)(&Load$$AP_SYS_CODE$$Base),
                (uint32)(&Image$$AP_SYS_CODE$$Base),
                (uint32)(&Image$$AP_SYS_CODE$$Length),

                (uint32)(&Load$$AP_SYS_DATA$$Base),
                (uint32)(&Image$$AP_SYS_DATA$$RW$$Base),
                (uint32)(&Image$$AP_SYS_DATA$$RW$$Length),

                (uint32)(&Image$$AP_SYS_DATA$$ZI$$Base),
                (uint32)(&Image$$AP_SYS_DATA$$ZI$$Length),
            },
}
Thus I can overlay different function module. Yes ,I can get the value of (uint32)(&Load$$AP_SYS_CODE$$Base) and (uint32)(&Image$$AP_SYS_CODE$$Length) like Thomas's suggesting, but I can not get the value of (uint32)(&Image$$AP_SYS_CODE$$Base), because this value only can be found in the output *.elf file, but I want to use this value in the compiler and linker. How can I do?

Best regards.

Hi riptide,

The __start_<section name> and __stop_<section name> identifier resolve to the runtime address (VMA) so I would rather say that it gives you &Image$$AP_SYS_CODE$$Base and &Image$$AP_SYS_CODE$$Length but not (&Load$$AP_SYS_CODE$$Base.

From reading ld's documentation about orphan sections [1], I think the logic is that ld will only define extra symbols if there is no way for you to have the information. For non orphan section, the load address (LMA) and runtime address (VMA) is decided from the linker script. Therefore, you can simply add symbol assignment in the linker script to get the beginning, end and length of a given section, much like is done to define __bss_start__ and __bss_end__ for instance. For orphan section this is not possible since by definition they are not mentioned in the linker script (but included nonetheless in the output file). Since by default, the VMA and LMA are equal and the only way to make them unequal is by using the AT command in the linker script, it makes sense to not have anything to get the load address of an orphan section (it's just the same as the runtime address).

[1] https://sourceware.org/binutils/docs-2.25/ld/Orphan-Sections.html#Orphan-Sections

Hope this helps.

Best regards.

Hi, Thomas,
    That is means that we can not get the load address in code like armcc if the VMA and LMA is not equal ?
    Thanks for your kindly help.

Best regards

Hi, Thomas,
    Thanks for your kindly information.
    I'll modify my linker script and do some testing, if there is any result, I'll let you know, thanks.

Best regards.

Thanks Thomas Preud'homme, that solved my question.