About overlapped sections

da cheng

Dear All,

What happened to my .map files? I have two .map files here, for both of them, the following two output sections are overlapped.

It is weird. Thank you very much.

.map 1: .cinit is overlapped with .text

.cinit     0 00000000    0000089c     COPY SECTION
                  00000000    0000080a     main.obj (.cinit)
                  0000080a    00000006     --HOLE-- [fill = 0]
                  00000810    0000002c     rts6700.lib : exit.obj (.cinit)
                  0000083c    00000004     --HOLE-- [fill = 0]
                  00000840    00000025     vm3224k.obj (.cinit)
                  00000865    00000003     --HOLE-- [fill = 0]
                  00000868    0000001c     rts6700.lib : _lock.obj (.cinit)
                  00000884    00000004     --HOLE-- [fill = 0]
                  00000888    00000010                 : rand.obj (.cinit)
                  00000898    00000004     --HOLE-- [fill = 0]

.text     0 00000000    000073a0
                  00000000    00006320     main.obj (.text)
                  00006320    000007c0     vm3224k.obj (.text)
                  00006ae0    00000240     rts6700.lib : memcpy62.obj (.text:_memcpy)
                  00006d20    00000140                 : autoinit.obj (.text:__auto_init)
                  00006e60    00000140                 : exit.obj (.text:_exit)
                  00006fa0    00000120                 : divi.obj (.text:__divi)
                  000070c0    00000100                 : remi.obj (.text:__remi)
                  000071c0    000000e0                 : rand.obj (.text:_rand)
                  000072a0    00000080                 : boot.obj (.text:_c_int00)
                  00007320    00000040                 : args_main.obj (.text:__args_main)
                  00007360    00000020                 : exit.obj (.text:_abort)
                  00007380    00000020                 : _lock.obj (.text:__nop)

.map 2: .cinit is overlapped with .far

.cinit    0   00000000    00014cec     COPY SECTION
                  00000000    0001474a     main.obj (.cinit)
                  0001474a    00000006     --HOLE-- [fill = 0]
                  00014750    00000244     rts6700.lib : defs.obj (.cinit)
                  00014994    00000004     --HOLE-- [fill = 0]
                  00014998    0000012c     csl6713.lib : csl_irq.obj (.cinit)
                  00014ac4    00000004     --HOLE-- [fill = 0]
                  00014ac8    0000005c     rts6700.lib : lowlev.obj (.cinit)
                  00014b24    00000004     --HOLE-- [fill = 0]
                  00014b28    00000058     c6713dskinit.obj (.cinit)
                  00014b80    00000054     csl6713.lib : csl_mcbsp.obj (.cinit)
                  00014bd4    00000004     --HOLE-- [fill = 0]
                  00014bd8    00000030     dsk6713bsl.lib : dsk6713_aic23_registers.obj (.cinit)
                  00014c08    0000002c     rts6700.lib : memory.obj (.cinit)
                  00014c34    00000004     --HOLE-- [fill = 0]
                  00014c38    0000002c                 : exit.obj (.cinit)
                  00014c64    00000004     --HOLE-- [fill = 0]
                  00014c68    00000028     dsk6713bsl.lib : dsk6713_aic23_setfreq.obj (.cinit)
                  00014c90    00000025     vm3224k.obj (.cinit)
                  00014cb5    00000003     --HOLE-- [fill = 0]
                  00014cb8    0000001c     rts6700.lib : _lock.obj (.cinit)
                  00014cd4    00000004     --HOLE-- [fill = 0]
                  00014cd8    00000010                 : rand.obj (.cinit)
                  00014ce8    00000004     --HOLE-- [fill = 0]

.far    0 00000200    00015200     UNINITIALIZED
                  00000200    0001466e     main.obj (.far)
                  0001486e    00000002     dsk6713bsl.lib : dsk6713.obj (.far)
                  00014870    00000374     rts6700.lib : defs.obj (.far)
                  00014be4    00000190                 : fcvt.obj (.far)
                  00014d74    00000190                 : _printfi.obj (.far)
                  00014f04    0000011c                 : lowlev.obj (.far)
                  00015020    000000f4     csl6713.lib : csl_irq.obj (.far)
                  00015114    000000d0     rts6700.lib : trgdrv.obj (.far)
                  000151e4    0000008c                 : exit.obj (.far)
                  00015270    00000064                 : ecvt.obj (.far)
                  000152d4    00000058     c6713dskinit.obj (.far)
                  0001532c    00000038     csl6713.lib : csl_mcbsp.obj (.far)
                  00015364    00000031     vm3224k.obj (.far)
                  00015398    00000028     dsk6713bsl.lib : dsk6713_aic23_registers.obj (.far)
                  000153c0    00000020                    : dsk6713_aic23_setfreq.obj (.far)
                  000153e0    00000008     rts6700.lib : _lock.obj (.far)
                  000153e8    00000008                 : memory.obj (.far)
                  000153f0    00000008                 : rand.obj (.far)
                  000153f8    00000008     dsk6713bsl.lib : dsk6713_aic23_opencodec.obj (.far)

over 15 years ago

0 Brad Griffis over 15 years ago

TI__Guru*** 125430 points

Looks like you have --ram_model set in your linker options. Use --rom_model instead to get rid of that behavior. You can read more about these options in the Assembly Language Tools Guide.

0 da cheng over 15 years ago in reply to Brad Griffis

Intellectual 370 points

Does that mean that the .cinit information in .map is useless in RAM_model?

If so, is there a file that can show what the memory's content is? Or can I say, the only redundant part that I can remove, is .cinit section?

Many thanks to your reply.

0 George Mock over 15 years ago in reply to da cheng

TI__Guru**** 251020 points

You are linking with --ram_model. This means the .cinit section is a COPY section. A COPY section is not like a normal section such as .text. For more info on COPY sections, and other special types of sections, see http://www-k.ext.ti.com/sc/technical-support/knowledgebase.asp?kb=dsp&Case=52185 . The key point is that a COPY section is not allocated to target memory. It doesn't overlay anything.

When .cinit is created like that, there is a presumption that the loader (such as the loader built-in to CCS) knows the format of the .cinit tables and how to use them to initialize variables in RAM memory space (i.e.. the variables in the .bss section). If you do not have such a loader in your system, then you should not use --ram_model. Use --rom_model instead.

Thanks and regards,

-George

0 da cheng over 15 years ago in reply to George Mock

Intellectual 370 points

Hello!

Do you mean the ROM_model is only for simulation/debugging phase? Because if you directly initialize during load.

All those information is put into RAM right? Then if there is power off. Everything is gone. However, ROM_model keeps the initialization information.

Thus whenever power off and power on, we have the initialized data.

Am I right? the key point here is we have to use a rom or flash to store program(code+data), right? At the point, the RAM_model does put program into RAM instead of ROM or Flash.

0 George Mock over 15 years ago in reply to da cheng

TI__Guru**** 251020 points

The C6000 compiler book http://www.ti.com/lit/pdf/spru187 has a section on this topic titled System Initialization. I think it will answer your questions.

Thanks and regards,

-George

Code Composer Studio™︎

Code Composer Studio forum

About overlapped sections