• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 1264 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler: TDA2XX A15 gnu linker section allocation problem

Guy Mardiks
Genius 4135 points


Tool/software: TI C/C++ Compiler

Hi,

Compiling to the ARM A15 on the TDA2xx , using the gnu tools

I am trying to allocate an assembly code to a specific location.

In the assembly code i wrote 

.section .mysec

in the linker file i have:

MEMORY

{
    MY_MEM (RWIX): org = (0x40300000) , len = (0x10000) 

}

SECTIONS {

.mysec(0x40300000) :
{
    KEEP(*(.mysec))
   KEEP(*(.mysec.*))
}

....

.text   : { *(.text) *(.text.*) }   AT > MY_MEM

....

}

When looking at the resulted map file i can see that the .mysec was allocated correctly with an appropriate size but from some reason the .text is also allocated to the same location.

From the MAP file:

.mysec0x40300000 0xdc
*(.mysec)
.mysec  0x40300000 0xdc  ./src/my_tda2xx_init.o
0x40300000 my_Start
0x403000a0 Jump_main
0x403000a4 Clear_Bss_Section
*(.mysec.*)

.public
*(.public.*)

.init
*(.init.*)

.text 0x40300000 0x1982c
*(.text)
.text 0x40300000 0x1f0 ./src/exceptionhandler.o
0x40300000 SVC_Handler
0x40300078 IRQHandler
0x40300118 FIQHandler
0x403001a8 AbortHandler
0x403001c8 UndefInstHandler
.text 0x403001f0 0x48 ./src/sbl_lib_tda2xx_hs_support.o
0x403001f0 SBLLibHSSecureEntryAsm

...

The assembly that has the code for the "overloaded function" (i.e. IRQHandler ,... ) only defines .text at the start

I don't understand why the linker does this - does the gnu linker do not recognize absolute addresses as part of the memory?

Please help

Thanks

Guy

  • 0
    TI__Guru**** 251670 points

    This looks like a bug in the ARM GCC linker.  I have reproduced it.  I have never submitted a bug against the ARM GCC linker, so the next step is to learn how to do that.

    Keep in mind this possibility ... This may not be a bug, but intended behavior somehow.  If that is the case, filing the bug should result in an explanation.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Genius 4135 points

    Hi, Thank you.
    After some more digging I found out that i have to also set the proper flags for a named section in gnu as (assembly), otherwise the default is that section is set as a non-allocated section - which explains why the linker ignored it and place another section on the same address range.
    After setting the flags it seems to be working as expected.

    Thanks
    Guy

  • 0 in reply to Guy Mardiks
    TI__Guru**** 251670 points

    Then it is a good thing that I did not file a bug.  Please show the syntax you used to set the proper flags for the section.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Genius 4135 points

    Hi,

    I used :

    .section .mysec ,"ax", %progbits (since i need code section).

    you can see all the flags in the as manual , the important thing to remember is that if no flags are set, the default is a NON-Allocated section.

    I am still having problems with the gnu linker. i was under the assumption that there is no guarantee on the order of the output sections allocation in memory - that is why TI linker for example have the GROUP  keyword.

    It seems however the for gnu linker sections are ALWAYS mapped according to the order of they appearance in the linker script file (when assigned to the same memory region). moreover if specifying a specific start (VMA) address for a section the linker always place the section on that address and will not check if any previous section was allocated there also which will effectively create overlay sections. for load addresses it seems the linker also always assign load addresses in the order of sections appearance and if specifying a specific load address, it issues error is if a previous section was already assigned and the address is falls in that range - i.e. it does not first allocate the sections that have a specific addresses and than resolves the rest).

    moreover it seems that when specifying a unique VMA I also must still associate the section with a memory region otherwise it will try to load the next section on the same addresses which results in an errror:

    This results in an error about .text and .sec1 are loaded to the same addresses

    .sec1 (ORIGIN(MEM1)) :

    {

    *(.sec1)

    }

    .text   : {*(.text) *(.text.*) }    AT > MEM1

    While this seems to be fine :

    .sec1 (ORIGIN(MEM1)) :

    {

    *(.sec1)

    } >  MEM1

       .text   : {*(.text) *(.text.*) }    AT > MEM1

     

    I have not been able to find any documentation that actually describes and says that this is the behavior  and it would be great if you will be able to confirm / contradict this and also explain how the gnu linker actually sets the VMA and LDA addresses of the sections .

    I truly am confused about this linker logic and behavior as to assignment of  the VMA and LMA to sections and don't know anymore what i a can rely upon 

    Any help you can give will be much appreciated...

     

    Thanks

    Guy