• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 2445 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.

GNU ARM tools - linker

Guy Mardiks
Genius 4135 points


Hello,

I am using the gnu tools for the A15 (using the TDA2xx SOC).

1. I have had a general (maybe old) gnu linker manual in which there is a note that says:

" ... Note that if the section has not had a VMA assigned to it then the linker will use the lma region as the VMA region as well. ..."


Lately i have looked at the ld pdf that comes with the arm gnu package (in the gcc-arm-none-eabi-4_9-2015q3 package) and i could NOT find this note anywhere in this document.

Does this mean that the above note no longer applies and i must specify both LMA and VMA regions if i want to be certain of allocation (i dont want to leave LMA not defined as it may calculate it using a VMA- LMA offset of a previous section which may not be desired so i want to control it)? - does the same answer also applies to the TI linker?

2.

Can you explain what should be the value and behavior of the section location counter (both for GNU and for TI linkers) if read / set  between output section blocks (outside of an output section block) where each of the sections may have different memory regions? 

according to the doc assigning value to the . operator defines the start address of the following output section (if not specifically set for the section) - how does this works when sections are assigned to different regions?

"... the linker assumes that an assignment to . is setting the start address of a following output section ..."

I will appreciate if you can explain and elaborate more on this.

3.

When setting input sections to output sections, if i am using the syntax *(.text) i see it only applies the all .text output sections and any input section that is .text.xxxx is not considered and a subgroup and a dedicated output section is created for it - as a result the assignment of a memory region the the .text.xxxx is determined by the linker according to internal logic which may not be what was intended.

on an A15 linker script example , i  have seen that for .text there is only reference to *(.text) but for the .data, for example, there is a reference to both .data (as this is the name of the output section so input esections with the same names will be assigned to it) and to all .data.xxxx ( *(.data.*) ):

.text : { *(.text) } > MEM1
.data : { *(.data.*) }  >MEM2

is there a reason why the .text output section do not include also *(.text.*)? can you explain ? am i wrong in my understanding above?

4.

The TI linker has a GROUP option to force several output sections to be allocated contiguously, is there something similar for the gnu linker (i could not find one)?

Thanks

Guy

  • 0
    TI__Genius 17215 points
    Hi Guy,

    We will be moving this thread to TI Compiler forum. Additionally, generic questions regarding GNU compiler behavior can be checked on Linaro forums.

    regards
    Yashwant
  • 0
    TI__Guru**** 251060 points

    I am confident in my knowledge of TI linker command files.  I have much less confidence regarding GCC linker scripts.  But since no else is answering here, I'll shed what light I can.

    Guy Mardiks said:
    Does this mean that the above note no longer applies and i must specify both LMA and VMA regions

    That is most unlikely.  A change like that in the GCC linker would cause it to act differently for many linker scripts already in the field.

    Guy Mardiks said:
    does the same answer also applies to the TI linker?

    With regard to the TI linker, the VMA corresponds to the run address, and the LMA corresponds to the load address.  By default, they match.  You can make them different only by explicitly giving a different allocation to run and load.

    Guy Mardiks said:
    Can you explain what should be the value and behavior of the section location counter (both for GNU and for TI linkers) if read / set  between output section blocks (outside of an output section block) where each of the sections may have different memory regions? 

    The TI linker does not have the concept of a location counter between sections.

    In a GCC linker script, if you explicitly specify a memory region for a section, then the location counter value is ignored.

    Guy Mardiks said:

    .text : { *(.text) } > MEM1
    .data : { *(.data.*) }  >MEM2

    is there a reason why the .text output section do not include also *(.text.*)?

    I am confident you are correct to conclude these two lines work differently.  I don't know why your example script does it this way.  Where does it come from?  Be as specific as you can.  Exactly which software package, which version, and so on.  My goal is to find the team responsible for that script, and ask them.

    Guy Mardiks said:
    The TI linker has a GROUP option to force several output sections to be allocated contiguously, is there something similar for the gnu linker

    I hesitate to answer, because while I think I know, I cannot find anything in the documentation which explicitly spells this out. I think you don't need GROUP in a GCC linker script.  I am certain that if you depend on the location counter method of address allocation, sections are allocated in the order you write them.  When you allocate multiple sections to the same memory region, I suspect they also go in the same order.  It is this last thing that I cannot confirm in the documentation.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Genius 4135 points
    Hi George,
    Unfortunately i don't remember where i have seen the example that had the different sections syntax for .text and .data - when i saw it it felt weird so i thought so ask about it.
    what you can see though is that some of the examples has both the *(.sec) and *(.sec.*) and some only the
    *(.sec) . from what i recall (From previous work i did) is that there are compiler options that assign each variable/function a section of its own named secName.varName / secName.funcName and this helps the unused functions and variable removal process. if there is no mentioning of the *(.secName.*) wouldn't this cause these functions / variables not to be placed on the desired memory region? it feels like the addition of the *(.sec.*) is a must if memory regions are important - can you give your input on this? (unless, and i have not seen this mentioned anywhere, all the sec.* are placed always in sec if there is not other specific assignment for them)?

    Thanks
    Guy
  • 0 in reply to Guy Mardiks
    TI__Guru**** 251060 points

    I apologize for the delay.

    I lack the experience with the GCC ARM compiler that might allow me to to answer this question in the abstract.  I need to know what section names the compiler usually produces.  From that, I suspect I could then make an educated guess as to why those lines are written that way.  When I tried to find what section names are used, I could only find vague documentation.  Apparently, this detail is left to target specific configuration mechanisms in each GCC compiler, and are never explicitly spelled out.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Genius 4135 points
    Hi, Thanks.
    Will you be able to ask around with the gnu guys (linaro forum?) to understand the linker behavior and logic?

    Thanks
    Guy
  • 0 in reply to Guy Mardiks
    TI__Guru**** 251060 points

    At this point, I think it makes sense for you to directly work with the GCC ARM team.  Please visit support.linaro.org.  Click the Sign Up link to request an account.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Genius 4135 points
    Thanks.
    (I didn't try to register before because i got the impression from previous answers that not anyone can register to that form)