• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 52 subscribers
  • Views 1578 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Changing COFF to EABI

Jasmeet Kaur97544
Intellectual 420 points

While changing COFF to Eabi, I encounter certain issues, e.g.

changing .bss to __TI_STATIC_BASE doesn't work, (it is not recognised by the linker), which states that it is an undefined symbol.

Though .cinit works!

Also, how should I replace the symbols 'end', 'etext', in the statements such as LDR r1,end (since end and etext are N/A in EABI).

I followed the instructions given at http://processors.wiki.ti.com/index.php/C6000_EABI_Migration, hoping that this works for all processors.

  • 0
    TI__Guru* 84225 points

    I gather you are not using C6000?  Are you using ARM or MSP430?

  • 0 in reply to Jasmeet Kaur97544
    TI__Guru* 84225 points

    For ARM, please see http://processors.wiki.ti.com/index.php/EABI_Support_in_ARM_Compiler.  Unfortunately, the migration document referred to there does not answer your question.

    For ARM, __TI_static_base__ exists, but it points at the start of the .cinit section, which is surprising to me.  I don't see a linker-defined symbol that could be used in place of the symbols "end" or ".bss".  You may need to create such a symbol in the linker command file.  I'll try to get an expert to comment on this.

    For those reading along, "end" is the linker-defined COFF symbol marking the end of uninitialized data (usually the end of .bss).  You can find documentation in the ARM Assembly Language Tools User's Guide, SPNU118 revision J, in section "7.5.8.4 Symbols Defined by the Linker"

  • 0 in reply to Archaeologist
    TI__Guru* 84225 points

    Okay, ignore __TI_static_base__ entirely.  On ARM, it is unrelated to .bss

    You can create your own ".bss" and "end" symbols with the RUN_START and RUN_END linker command file operators.  For example:

    .bss : RUN_START(.bss), RUN_END(end) {} > D_MEM
  • 0 in reply to Archaeologist
    Intellectual 420 points

    Does that mean I can replace the earlier definition(COFF) of bss i.e 

    .bss: { }  

    with

     .bss : RUN_START(.bss), RUN_END(end) {} > D_MEM

    What should I do with the symbol etext?

  • 0 in reply to Jasmeet Kaur97544
    TI__Guru* 84225 points

    Use the same approach:

    .text : RUN_START(.text), RUN_END(etext) {} > D_MEM

    This may not be quite what you want if you have more than one text section. You may need to gather all text sections into one .text output section, or place them in a group and use the RUN_START and RUN_END operators on the group.

  • 0 in reply to Archaeologist
    Intellectual 420 points

    Thanks a ton, I'm done away with the errors, but for the .bss section in the linker command file, I get a warning:

    #10083-D LOAD placement ignored for ".bss":  object is uninitialized

    Searching the e2e community, I found this thread,

    http://e2e.ti.com/support/development_tools/compiler/f/343/t/66645.aspx

    but can't conclude anything, kindly explain.

  • 0 in reply to Jasmeet Kaur97544
    TI__Guru* 84225 points

    You must use RUN_START and RUN_END, and not START and END (which mean LOAD_START and LOAD_END), when applied to uninitialized sections like .bss

  • 0 in reply to Archaeologist
    Intellectual 420 points

    I have used RUN_START and RUN_END only, with the .bss section, still I get this warning.

  • 0 in reply to Jasmeet Kaur97544
    TI__Guru* 84225 points

    Please post the exact SECTIONS directive you are using for .bss

  • 0 in reply to Archaeologist
    Intellectual 420 points

    I'm using the same statements as you suggested. I'm running the .bss and .text in a group as follows:

    GROUP

    {

    RamActiveBlk : {}

    .bss : RUN_START(.bss), RUN_END(end) {} > D_MEM

    .text : RUN_START(.text), RUN_END(etext) {} > D_MEM

    } run = XYZ align 0x4, START(StartAddr), END(EndAddr)

     

    and I get the specified warning in the .bss line.

  • 0 in reply to Jasmeet Kaur97544
    TI__Guru* 84225 points

    You're placing each group member into D_MEM, and also placing the group into XYZ at run-time.  Remove the "> D_MEM" from .bss and the warning will go away.

    I'm a bit unclear exactly how the ">" syntax, the "run=" syntax, and the use of the GROUP operator interact.  I'll have to ask an expert on this subject.

  • 0 in reply to Archaeologist
    TI__Guru* 84225 points

    Okay, this is a bit complicated to explain, so here's the simplified version:

    Members of a group always inherit the run specifier of the group, which in this case is 'run=XYZ'.  Furthermore, inside a group, the '>MEM' operator is interpreted to mean 'load=MEM', because the run specifier is already known from the group.

    Outside of a group, the '>MEM' operator means 'run=MEM load=MEM as necessary'.  In this case, .bss doesn't need a load address, but it does need a run address.  The linker interprets '>MEM' as 'run=MEM' and ignores the load part.

    However, inside the group, where '>MEM' only means 'load=MEM', the linker realizes that .bss doesn't need a load specifier, so the '>MEM' operator is totally useless, and the linker emits a warning.

    Summary: don't use the 'load', 'run', or '>' operators inside a group unless you really want different load and run addresses, in which case only use 'load' or '>', and only on initialized sections.