• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 53 subscribers
  • Views 2424 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.

Initialization of .far and .fardata section

Fabian Lindner
Intellectual 880 points

Hi,

I am a little bit confused about the initialization behavior of the .far and the .fardata section. I am compiling using v7.4.2 in EABI mode (Yes I already have read about the differences between EABI and COFFABI). In addition I used ROM model as autoinitialization mode.

From what I have read in SPRU187 page 237 I expected the sections .far and .fardata being uninitialized at load time and only getting initialized by cinit. This is also, what I observe when I analyze the loading procedure by CCS.

But when I look at the generated .map file I get confused: I expected the .far section being marked as UNINITIALIZED as I was used to under COFFABEÍ mode, but there is no mark. Only heap and stack are marked as UNINITIALIZED.

So I just wanted to know if the .out file has contains data at the address of the .far section or not? I just need to know wheather a bootloader has to load data at this address or wheather this is done in the cinit of the program

Regards Fabian

  • 0
    TI__Guru**** 232670 points

    Fabian Lindner said:
    when I look at the generated .map file I get confused: I expected the .far section being marked as UNINITIALIZED

    I suspect that is due to some bug in the linker.  Even so, I cannot reproduce this behavior.  The .far section is uninitialized.

    Fabian Lindner said:
    I just need to know whether a bootloader has to load data at this address or whether this is done in the cinit of the program

    When the system starts, both the .far and .fardata sections are uninitialized.  The startup routine (_c_int00 from the compiler RTS library) processes records in the .cinit section which have 2 effects.  1) The .far section is initialized to all 0.  2) The .fardata section is initialized with explicit values as specified in the C source.  So, your bootloader needs to load .cinit, but not .far or .fardata.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 880 points

    Thanks for the quick answer. That's all I need to know

    Regards Fabian

  • 0 in reply to George Mock
    Intellectual 575 points

    Hi,

    I have to dig out that thread again, since I have a similar issue. I also noticed the .far and .fardata section not being marked UNINITIALIZED in the map file. This is important to us because we have an automated script which determines the actual used sections and the final binary file size. And these .far and .fardata sections not being marked as UNINITIALIZED lead to a much larger binary.

    George Mock said:
    I suspect that is due to some bug in the linker.

    Even with the current cgtools linker (7.4.8) this bug still persists. Is there any chance this bug will be fixed soon?

    Thanks and greetings,
    Thomas.

  • 0 in reply to Thomas Doering
    TI__Guru**** 232670 points

    Thomas Doering said:
    I also noticed the .far and .fardata section not being marked UNINITIALIZED in the map file

    I just tried a small test case.  In the map file the .far section is marked UNINITIALIZED, but the .fardata section is not.  So, I can reproduce half of what you complain about.  I suppose I could file a bug over that.  But I prefer to reproduce both problems, and file a bug over that.  I'd appreciate a test case that lets me do that.  Are you building with CCS?  Is there any chance you could send me the project?

    Thomas Doering said:
    This is important to us because we have an automated script which determines the actual used sections and the final binary file size

    As an alternative, consider using the script sectti from the cg_xml package.  It handles .far and .fardata as you expect.  You can even use it to see how object files have .fardata as initialized, and the final linked executable have .fardata as uninitialized.

    Another alternative to consider: Use tiobj2bin, also in the cg_xml package, to create the binary file.

    Thanks and regards,

    -George