• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 55 subscribers
  • Views 2045 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.

Need example or guide on how to set a fill value of 0 in the linker control map for the .bss section.

Yu Liu
Prodigy 600 points

Hi SDO Experts,

For details see section 7.8.1 of the Compiler User's Guide (SPRU187O.pdf). Here is the note from that section:

"In ANSI/ISO C, global and static variables that are not explicitly initialized must be set to 0 before program execution. The C/C++ compiler does not perform any preinitialization of uninitialized variables. Explicitly initialize any variable that must have an initial value of 0. The easiest method is to set a fill value of 0 in the linker control map for the .bss section. You cannot use methods with code that is burned into ROM."

Is there any detail on how to fill value of 0 in the linker control map for the .bss section?

Thanks & Regards,

Yu Liu

  • 0
    TI__Guru**** 171839 points

    Yu,

    The Assembly Language Tools User's Guide (SPRU186R) has some instructions on how to fill the variables using linker options and directives in the linker command file (.CMD). Check the following sections:

    - Section 7.4 mentions the linker option -f or --fill_value to properly fill holes between memory sections.

    - Sections 7.5.3 and 7.5.4 show how to use the fill directive to properly fill either memory segments or sections in the linker command file.

    Yu, I am moving this post to the external forum as it may help other customers as well, ok?

    Hope this helps,

    Rafael

     

  • 0 in reply to desouza
    TI__Genius 9375 points

     

    I was actually playing with this a few days back and had a follow up question on this:

    I was playing with a linker command file with the following syntax:

       .stack:  fill=0x12341234   >       EXT
        .bss : fill=0xc0ffee   >       EXT
        .cinit: fill=0xabababab      >       EXT
         .data  fill=0xdeadbeef     >       EXT

        .cio        >       EXT
        .const      >       EXT
    And in addition had the linker -f set to 0xaabbccdd

    I do see my map file having the stack, bss, and cinit being 'fill'ed correctly except for the following:

    .cinit     0    800288e0    000001a4    
                      800288e0    0000005c     rts6400.lib : defs.obj (.cinit)
                      8002893c    00000004     --HOLE-- [fill = abababab]
                      80028940    0000005c                 : lowlev.obj (.cinit)
                      8002899c    00000004     --HOLE-- [fill = abababab]
                      800289a0    0000003d     main.obj (.cinit)
                      800289dd    00000003     --HOLE-- [fill = abababab]
                      800289e0    0000002c     rts6400.lib : exit.obj (.cinit)
                      80028a0c    00000004     --HOLE-- [fill = abababab]
                      80028a10    0000002c                 : memory.obj (.cinit)
                      80028a3c    00000004     --HOLE-- [fill = abababab]
                      80028a40    0000001c                 : _lock.obj (.cinit)
                      80028a5c    00000004     --HOLE-- [fill = abababab]
                      80028a60    00000010                 : divd.obj (.cinit)
                      80028a70    0000000c                 : fopen.obj (.cinit)
                      80028a7c    00000004     --HOLE-- [fill = abababab]
                      80028a80    00000004     (.pad.cinit) [fill = 0]

    Why is this final entry 0? I know default is '0' but I thought that is overridden by the -f 0xaabbccdd.

    Also I noticed in my map file I have:

    .sysmem    0    800284e0    00000400     UNINITIALIZED
                      800284e0    00000008     rts6400.lib : memory.obj (.sysmem)
                      800284e8    000003f8     --HOLE--

    where the HOLE is not filled with anything. So, am I right in understanding that uninitialized sections do not get filled unless explicitly using the fill command in the SECTIONS part of the linker command file. The -f option is really only applicable to initialized sections or output sections which have holes?

     

    Rgds

    -Dipa-

  • 0 in reply to TIDR
    TI__Guru**** 171839 points

    Dipa,

    Are you using palign in your linker command file? If so, the last sentence of section 7.5.4.2.5 of the SPRU186R says that all padding is done with a value of 0 for uninitialized sections, no matter what the fill value.

    I don't see anything in this document that explains the second issue, though. Section 7.4.10 does not explicitly mention any restrictions with regards to initialized or uninitialized sections.

    Did you see what values were actually written to the target? This could help see if the fill value is only wrong at the map file or it is actually present in the .out. Before loading the .out make sure to fill the memory region of interest with something like 0xCAFECAFE.

    Cheers,

    Rafael

  • 0 in reply to TIDR
    TI__Guru**** 253450 points

    With regard to the .cinit section, Dipa asks ...

    Dipa Rao said:
    Why is this final entry 0? I know default is '0' but I thought that is overridden by the -f 0xaabbccdd.

    The code which processes the .cinit section (to initialize global variables during system start) expects to find this zero.  It marks the end of the .cinit section.  While I've never tried, I suspect filling the .cinit section with anything will cause errors at runtime.  

    Thanks and regards,

    -George

     

  • 0 in reply to George Mock
    TI__Genius 9375 points

    Hi George,

    Yes, of course, I should've realized that. I didn't think of that when I was looking  at the map file.

    Hi Rafael,

    My experimentation seems to show that uninitialized sections need explicit fill so maybe that is not called out in the docs but thats the way it works.

    Rgds

    -Dipa-

  • 0
    TI__Prodigy 600 points

    1. If the array is global array, the COFF workaround of initializing the .far section in the linker command file should work and has the limitation of one time initialization.

    2. If the array is static local array, the COFF workaround of initializing the .far section in the linker command file should work and has the same limitation of one time initialization.

    3. If the array is local array, the compiler will generate code to initialize the local array every time the function is executed.