__FILE__ in a specific section in memory

The assert macro makes use of the predefined preprocessor symbol __FILE__.  __FILE__ is a constant quoted string like "filename.c"  In the specific case of assert, it is concatenated with the other constant strings that surround it.  This results in a final string similar to ...

"Assertion failed, (arg != 0), file filename.c, line 5\n"

There is no method by which you can directly tell the compiler where to store such a constant string.  The compiler stores strings like that in a section named ".const:.string".  Thus, in the linker command file you can do things like ...

    .const:.string > SPECIAL_MEMORY_RANGE

to put all of the constant strings in a particular memory range.

Thanks and regards,

-George

Thank you very much George for your answer.
I modified my cmd file but it doesn't work.

In my source code I wrote :
========================
char *FileName = __FILE__;

In my cmd file :
=============
-priority
--trampolines
-stack 0x0400
-heap 0x7000

MEMORY {
CACHE_L1P : origin = 0x11e00000, len = 0x8000
CACHE_L1D : origin = 0x11f00000, len = 0x8000
DDR : origin = 0xc0000000, len = 0x8000000
IRAM origin = 0x11800004, len = 0x4000
}
SECTIONS
{
.const:.string > DDR

.far: > IRAM
.mem: > IRAM
.data: > IRAM
.cio: > IRAM
.pinit: > DDR
.text: > IRAM
.cinit: > DDR
.switch: > IRAM
.sysmem: > IRAM
.stack: > IRAM
.bss: > IRAM
.const: > IRAM
.data: > IRAM

}
Problem:
========
The linker always allocate FileName in section IRAM and not in DDR.
Maybe do you have some suggestion ?
Thank you very much in advance for your answer.

Regards.

Pat.

I presume you are building for the older ABI named COFF ABI.  If you build for the newer EABI, some details are different, though the overall concept is the same.

This source line ...

lavenu patrick1 said:

char *FileName = __FILE__;

allocates two different things to memory.  The global char pointer FileName is allocated to the section named .bss.  The constant string "source_file_name.c" (or whatever __FILE__ is) is allocated to the section named .const:.string.  I'm sure the string ends up in DDR.  The char pointer FileName is in IRAM, along with the rest of .bss.  

You can name the section for FileName with #pragma DATA_SECTION.  Read about in the C6000 compiler manual.  Something similar to this would work:

#pragma DATA_SECTION(FileName, "special_section_name")
char *FileName = __FILE__;

Thanks and regards,

-George

Thank you very much George for your answer.

I confirm you that if I write .const:.string > DDR in my cmd file , it doesn't work.

My global char pointer is in .bss section in IRAM but my const string is in IRAM too. If I want to have my const string in DDR, I have to change :
.const > IRAM to .const > DDR
in my cmd file and then it works.

You are right, I'm using COFF format. I made a test with the ELF format and it doesn't work too. The only thing that is changing is that I have no char pointer in .bss section with ELF format.

maybe an idea ? thank you in advance for your help.

Best regards.

Pat.

PS : i'm using TI V7.3.1 compiler

lavenu patrick1 said:

I confirm you that if I write .const:.string > DDR in my cmd file , it doesn't work.

I am unable to reproduce this behavior.  You need to send a more complete test case.  Please show the exact options used when compiling and linking.  Do you have this organized as a CCS project?  If so, please submit it.

Thanks and regards,

-George

Thanks again for your help George.

I have a CCS 5.1.1 project but I don't know how to send it to you.

To resume:

================== MAIN.CPP ===============
#include "stdio.h"

const char *FileName=__FILE__;

int main(int argc, char** argv)
{
printf("File Name : %s,",FileName);
return 0;
}

=============== CMD FILE ==================
-priority
--trampolines


-stack 0x0400
-heap 0x8000

MEMORY {
CACHE_L1P : origin = 0x11e00000, len = 0x8000
CACHE_L1D : origin = 0x11f00000, len = 0x8000
DDR : origin = 0xc0000000, len = 0x8000000
IRAM : origin = 0x11800004, len = 0x40000
}

SECTIONS
{

. const:.string > DDR

.far: align = 0x4 {} > IRAM
.mem: align = 0x4 {} > IRAM
.data: align = 0x4 {} > IRAM
.cio: align = 0x4 {} > IRAM
.pinit: align = 0x4 {} > IRAM
.text: align = 0x4 {} > IRAM
.cinit: align = 0x4 {} > IRAM
.switch: align = 0x4 {} > IRAM
.sysmem: align = 0x4 {} > IRAM
.stack: align = 0x4 {} > IRAM
.bss: align = 0x4 {} > IRAM
.const: align = 0x4 {} > IRAM
.data: align = 0x4 {} > IRAM

}
=====================================

COMPILING OPTION :
-mv6740 -g --define="_DEBUG" --define="__EXCEPTIONS" --include_path="C:/Atgl/CCStudio/v5.1.1/ccsv5/tools/compiler/c6000/include" --display_error_number --diag_warning=225 --abi=coffabi

LINKING OPTION
-mv6740 -g --define="_DEBUG" --define="__EXCEPTIONS" --display_error_number --diag_warning=225 --abi=coffabi -z -m"FileNameTest.map" --warn_sections -i"C:/Atgl/CCStudio/v5.1.1/ccsv5/tools/compiler/c6000/lib" -i"C:/Atgl/CCStudio/v5.1.1/ccsv5/tools/compiler/c6000/include" --reread_libs --rom_model

=======================================

I hope it will help you to reproduce the problem. Thank you in advance for your answer.

Best regards.

Pat.

I still cannot reproduce the problem.  How do you know the constant strings from main.cpp are not in DDR?  When I look at the map file I see this ...

.const:.string 
*          0    c0000000    00000142     
                  c0000000    00000101     rts6740.lib : ctype.obj (.const:.string:__ctypes_)
                  c0000101    00000023                 : _printfi.obj (.const:.string)
                  c0000124    0000001c     main.obj (.const:.string)
                  c0000140    00000002     rts6740.lib : fputs.obj (.const:.string)

Note the .const:.string input section from main.obj.  Note how this entire output section is in the DDR memory range.

Thanks and regards,

-George

Thank you again for your answer.

My Map file looks like that :
================ MAP FILE ==========================
MEMORY CONFIGURATION

name origin length used unused attr fill
---------------------- -------- --------- -------- -------- ---- --------
IRAM 11800004 00040000 0000e75c 000318a4 RWIX
CACHE_L1P 11e00000 00008000 00000000 00008000 RWIX
CACHE_L1D 11f00000 00008000 00000000 00008000 RWIX
DDR c0000000 08000000 00000000 08000000 RWIX
......
.const 0 1180e378 0000016f
1180e378 00000101 rts6740.lib : ctype.obj (.const:__ctypes_)
1180e479 00000002 : fputs.obj (.const)
1180e47b 00000001 --HOLE-- [fill = 0]
1180e47c 00000048 Main.obj (.const)
1180e4c4 00000023 rts6740.lib : _printfi.obj (.const)
=============================================================

A you can see in my map file, the __FILE__ is in IRAM at address 0x1180e47c although I wrote .const:.string > DDR in my cmd file.
There is nothing in DDR and there is no ".const:.string" section in my map file.
It looks like the linker does'nt know the ".const:.string" section and consider the __FILE__ like "const" only.
An idea ? thank you very much.

Best regards.

Pat.

There is probably some important detail that you have overlooked.  I think if I get the full CCS project I can reproduce it.

lavenu patrick1 said:

I have a CCS 5.1.1 project but I don't know how to send it to you.

In CCS, right-click on the project name and choose Export.  In the next dialog expand the General selection and choose Archive File.  Click Next.  I think creating a .zip file is straightforward from that point.  Attach that .zip to your next post.

Thanks and regards,

-George

Thank you in advance for your analysis. I attached my zip file in the post, I hope it will works.

Best regards.

PatFIleNameTest.zip

I still cannot reproduce the error.  Though I did encounter one unusual thing.

When I first imported your project it wouldn't build.  The files Main.cpp and target.cmd are linked to somewhere in your file system.  I deleted them from the project, then copied-n-pasted them from the directory where I unzipped your files.  Then it built fine.  And I still don't see the problem with the .const section.  Sorry.

Thanks and regards,

-George

Hi Georges

I tried with a new version of CGT : 7.4.1 it works now.

There is a a problem in the 7.3.1 version.

Thanks again for your help and all your answers.

Best regards.

Pat.