Section usage in ASM and C mixed OMAP35x sources.

Just a quick thought, but is there really a ".cpmem" section, or a "cpmem" section?  You mention your assembly file has:

PE1PUP said:

        .sect "cpmem"

But the Linker command file has :

PE1PUP said:

        .cpmem  >       CP_MEM

I would not view these as being one in the same section, but uniquely different.

Perhaps this is not the issue, but please check this out.

Hello Brandon,

Thanks for your fast reply.

The "dot" in front of the section is a notation convention for these kind of Linker Command Files. For instance the "bss" section is also preceeded by a "." in this "SECTIONS" part of the command file, while in source it is referred to without the dot. So unfortenuately it does not solve my problem.

But your reply did make me try more variations. And this resulted in discovering that also without any section definition in de ASM part of my application, the ASM part is assembled but somehow not linked into the .OUT file. So my problem seems to be more fundamental.

I will do some further re-testing on a very basic mixed source application. In case someone has a good example in the meanwhile showing section assignments in ASM source, then please let me know. I will post my own results (and hopefully the solution) here too, when found...

Best regards, Johan.

In a small experiment, the section name used in the assembly file needed to be identical to the section name used in the linker command file.

If I used the following in an assembly file:

.sect "mysect"

and the following in the linker command file:

mysect :> MEMBLOCK

The code was allocated into mysect.

However, the following did not allocate the code in a similar way:

.sect "mysect"

.mysect :> MEMBLOCK

Hello Brandon,

You are right. The user-defined sections have to be identical in the .sect assembly statement and the linker command file. This was indeed an error in my programming. I was confused with the TI internal section names which all have a “dot” in front of them. Thank you very much for testing it for me and informing and correcting me.

But it turned out not to be my core problem. I now found the cause and solution after much trying and investigating. Let me tell you what I found, because it can be useful information for you and all other OMAP users:…

My small test application consists of just one ASM and one C source file. For compilation I use a self made linker command file. Let me give you my source files, just to show they are as simple as possible:…

The most complex file is the linker command file. And I made is so complex in order to give each memory section its own true memory location. This is just for test purposes, so not a practical situation. But for my section test it proved to be very useful. When I compile the whole mixed C-ASM application, I found that all is compiled and assembled, but somehow the ASM file is not linked into the .OUT file. And thus the ASM contents do not show in the MAP file. For reference I included the crucial part of this MAP file here:…

         name            origin    length      used     unused   attr    fill

----------------------  --------  ---------  --------  --------  ----  --------

  MEMBLOCK              40201000   00001000  00000000  00001000  RWIX

  TEXT_MEM              40202000   00001000  0000043c  00000bc4  RWIX

  DATA_MEM              40203000   00001000  00000014  00000fec  RWIX

  CINT_MEM              40204000   00001000  00000024  00000fdc  RWIX

  STCK_MEM              40205000   00001000  00000100  00000f00  RWIX

  HAND_MEM              40206000   00001000  00000004  00000ffc  RWIX

You see that the segment called MEMBLOCK is empty. It all points to the fact that somehow the linker does not take the object code generated from the ASM file into the linking process. And this made me find the solution. I forced the C source into making a dummy (non functional) reference to a label in the ASM file. I did this as follows:…

So all I added is a dummy and unused subroutine which calls any label in the ASM source file. And this forces the linker to also take the ASM object file into the linking process. The resulting MAP file shows that it indeed worked:…

         name            origin    length      used     unused   attr    fill

----------------------  --------  ---------  --------  --------  ----  --------

  MEMBLOCK              40201000   00001000  00000008  00000ff8  RWIX

  TEXT_MEM              40202000   00001000  00000448  00000bb8  RWIX

  DATA_MEM              40203000   00001000  00000014  00000fec  RWIX

  CINT_MEM              40204000   00001000  00000024  00000fdc  RWIX

  STCK_MEM              40205000   00001000  00000100  00000f00  RWIX

  HAND_MEM              40206000   00001000  00000004  00000ffc  RWIX

Now the MEMBLOCK segment contains some instructions. So just adding this dummy subroutine in C, which should never be called or used otherwise, makes the linker take all sources.

This was quite a surprise for me. This means that all source files which you would like to compile or assemble together into one big OUT file need to be somehow also linked on a source level. Just adding the files to the project is not sufficient enough. Just adding the files to the project just makes these files to be assembled and compiled, but not necessarily also linked together.

I think this is good to know. I needed to explore this because I do have an application in which the ASM part and the C part are completely individual. There is no source link between them But the TI linker forces me to make at least one dummy source link between them in order to obtain it all in one OUT file.

Brandon, again many thanks for your good and fast assistance. You “forced” me in the right direction.

Best regards, Johan.