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.

Placing .bss contents to user section

Other Parts Discussed in Thread: OMAPL138

Hello,

I've got a simple question concerning user defined linking. I read in spru187 and spru186 that accesses to non aggregate data is done via the data page pointer by default. The dp points to the beginning of the .bss section.  What happens if I use a library which is compiled as far aggregate (default) and move some symbols from the .bss section to my own section which is located far away from .bss? It shouldn't be possible to access the moved data via the dp, right? But there is no warning or error during the linking process. The application which uses the library is compiled with --mem_model:data=far.

 

Thanks in advance...

  • While objects in .bss are most efficiently accessed through DP, code is not required to use DP for every reference.  "Far" addressing modes may be used even for "near" objects. If you're not getting a linker error, either all of the code which refers to the objects you have moved use far addressing modes, or you didn't move it far enough away from the DP to matter.  You should be careful about moving things that the compiler placed in .bss; if you really want these objects to be outside DP access range, you should be declaring them "far" or using the appropriate options to enable far memory model modes.

    [Edit: grammar -- Archaeologist]

  • For further background on this see http://processors.wiki.ti.com/index.php/C6000_Memory_models .

    Thanks and regards,

    -George

     

  •  

    Below is the.bss content out of the map file.

    .bss       0    c3f1fc78    00000384     UNINITIALIZED
                      c3f1fc78    00000100     bios.a674 : hwi_disp_asm.o674 (.bss)
                      c3f1fd78    000000cc               : biosdata.o674 (.bss)
                      c3f1fe44    0000009c               : swi.o674 (.bss)
                      c3f1fee0    00000048               : knl.o674 (.bss)
                      c3f1ff28    00000028     bioscfg.obj (.bss)
                      c3f1ff50    00000020     bios.a674 : exc_asm.o674 (.bss)
                      c3f1ff70    00000018               : hwi.o674 (.bss)
                      c3f1ff88    00000018     lnkrtdx.a674 : rtdx.o674 (.bss)
                      c3f1ffa0    00000010     bios.a674 : exc.o674 (.bss)
                      c3f1ffb0    00000010     rtdx64xplus.lib : buffer1.o64P (.bss)
                      c3f1ffc0    00000010                     : rtdx_mon.o64P (.bss)
                      c3f1ffd0    0000000c     bios.a674 : tsk.o674 (.bss)
                      c3f1ffdc    00000008               : clk_data.o674 (.bss)
                      c3f1ffe4    00000008               : sys.o674 (.bss)
                      c3f1ffec    00000004               : clk_data2.o674 (.bss)
                      c3f1fff0    00000004               : idl_busy.o674 (.bss)
                      c3f1fff4    00000004               : knl_star.o674 (.bss)
                      c3f1fff8    00000004               : mem_asm.o674 (.bss)

    We use the OMAPL138 experimenter board and .bss lies in L2 RAM. When I move "bios.a674 : hwi_disp_asm.o674 (.bss)" to another section in L1 RAM which is more than 32k away from .bss there is no linker error. How is the bios library compiled? Our application is compiled with --mem_model:data=far. The content of .bss must be accessed as near inside the bios, right? So why is there no error when I move it away?

    Thanks

     

     

  • I'm pretty sure that BIOS explicitly defines all of its data with the "far" keyword.  Presuming that is true, then .bss sections from BIOS can be placed anywhere, and your memory model build options don't matter.  It will still work.

    Thanks and regards,

    -George

     

  • If all bios data is defined as far this explains everything. I always thought the .bss section only contains data which is defined as near. Am I wrong?!

    Thank you

  • When considering near and far on C6x, you need to consider not only whether the variable's actual definition is "near" or "far", but also (at each access) whether the variable has an external declaration which is "near" or "far".  (Or, instead of explicit "near" and "far" keywords, whether you are using small or large data model for that file.)  It's possible for a library to define a variable as "near", causing the variable to be placed in .bss, but to provide a "far" header file declaration, causing accesses to be made with a "far" instruction sequence.  Even though the variable shows up in a .bss section (meaning it was certainly declared "near"), this tells us nothing about whether the accesses saw a near or a far declaration, so we don't know whether the accesses use "near" or "far" instruction sequences.

    So yes, the fact that BIOS does have a .bss section means that some variable was defined "near."  However, it still might be the case that all accesses to it are far; I don't know.

    But again, I'd be leery of moving a section named ".bss" somewhere DP can't reach.

  • Just to be clear, I was wrong when I said ...

    Georgem said:
    I'm pretty sure that BIOS explicitly defines all of its data with the "far" keyword.

    Sorry about that.  I have some questions in to the BIOS folks about this.  Though I don't expect to get answers until next week.  Hope that's OK.

    Thanks and regards,

    -George

     

  • Hello,

    Archaeologist already answered my questions. It was just for my understanding and doesn't bring work to halt. I think BIOS defines the data as near so it is placed in .bss. The declaration of the data is far. Thus the data is placed in .bss but is accessed as far so there are no problems when moving the data away from .bss.

    Thanks for your information