Compiler/TMS320C6657: Linker generated $fill section for virtual addresses

I apologize for the delay.  I'm still working to understand what happened.  I have had trouble connecting with certain experts.  I expect to make more progress tomorrow, and may be able to advance the issue by then.

Thanks and regards,

-George

Dear George,

thanks for your reply. I would like to summarize the problem description:

If the compiler option --speculate_loads=auto is used, then the linker may add $fill sections before the related data sections, because the code may access before the valid data address.

The generated $fill section is not only a placeholder, instead it gives orders to fill the range with zeros.

Critical is the case where the related data have a virtualized address, e.g. in OpenMP the non-cached memory OMP_MSMC_NC_VIRT, where a piece of MSMCSRAM have a secondary address with disabled caching. The secondary address will be enabled at runtime by the OpenMP startup code (sets some MPAX registers). The base address of such virtual memory is e.g. 0xa000.0000.

Normally the $fill sections are placed at the end of BTBL file, generated by Hex6x tool.

During the boot process via RBL, the RBL is trying to load the $fill section to address 0xa000.0000, which is during the boot time not a virtualized address, instead the address is mapped to DDR3 (this is the default mapping). As result the RBL writes zeros to 0xa000.0000, which is mapped to 0x8000.0000 of DDR3.

 

Recommended behaviour of linker:

The correct behaviour of linker should be to generate $fill sections without filling with zeros (hole only), because only a placeholder is needed.

Workaround for usage with RBL:

Remove the generated $fill sections by Hex6x tool with parameter 

--exclude=$fill*

This generates a BTBL file without $fill sections, so that the RBL can load the program correctly.

Side effect for CCS debugging:

If the MPAX registers are not set already, then the CCS may also override the code/data at address 0x8000:0000 of DDR3 with the $fill section during the program loading.

I hope that summary help to understand the issue.

Kind regards

Sven

I apologize for the delay.

It turns out the linker never adds fill sections because of --speculate_loads=auto.  I thought that it did.  But I was confused.  I apologize.

Unfortunately, this means we are farther behind than before.  We don't know what is causing these fill sections to show up.  The only way to know what happened is to reproduce it.  For a linker issue like this, I need the complete CCS project.  Please archive it into a zip file as described in the article Project Sharing.  Then attach that zip file to your next post.

Thanks and regards,

-George

Dear Georg,

thanks for yur reply. As I wrote, I can not share my big project, because it uses some propritary code. I have tried to make a test project, but a simple project does not trigger the $fill behaviour of linker. I will try again next week to trigger the issue in a simple project.

I am wondering a little bit, because I have clearly descriped the $fill issue. Please, would you ask someone from the linker development team? They should find the code within the linker, where the $fill sections will be generated. After them the code should be changed as descriped in my last post.

Kind regards

Sven

Sven Mulka said:

Please, would you ask someone from the linker development team? They should find the code within the linker, where the $fill sections will be generated. After them the code should be changed as descriped in my last post.

That is exactly what I did. Nothing we see in your linker command file or build options should lead to automatic creation of a $fill section.  Yet that is what happens.  We must be missing a detail, or something similar.  That is why I ask for a test case.  I understand your difficulty with sending in a test case, which is why I am sorry I have to ask.  Nonetheless, it is the only way to advance this issue.

Thanks and regards,

-George

Sorry for the delay, I was not in the office last week.

Please, would you look in the lnk6x.exe file with any hex-editor or text-editor and search for "$fill", then you will see that the linker is the generator of $fill section. The related code may be located in the "../../master/ELFLNK/fill.c" file.

Please, would you explain the cases, where the linker should generate the $fill section normally?

Is here available any hidden linker option, that generates some more debugging information, which I can provide your?

Kind regards
Sven

Sven Mulka said:

Please, would you explain the cases, where the linker should generate the $fill section normally?

There is only one.  In the MEMORY directive, a fill=constant specification is available.  When used, this causes the linker to automatically create fill sections that occupy space in that memory range which is not used by any other output section.  Read more about it by searching for the sub-chapter titled MEMORY Directive Syntax in the C6000 assembly language tools manual.

You show your MEMORY directive in your first post.  No fill specification is used.

Thanks and regards,

-George

Dear Georg,

I confirm that the fill=n option in the MEMORY directive produces also $fill sections in the generated output file. This $fill sections are filling the complete MEMORY area, not only a small piece of them.

But nothing of that is used in my code. Instead the compiler option --speculate_loads=auto triggers also the generation of $fill sections at the beginning of used MEMORY sections in some special cases. Read more about it in section 4.6.3.2 of SPRUI04C 

 

 

In addition, the compiler communicates information to the linker to help automatically ensure the required pre- and post-padding:

• • If the symbol of the speculatively loaded buffer is known at compile time, the linker ensures the object pointed to by the symbol has the required padding to let the speculative load access legal memory.
  • If the symbol information is not known during compile time, the linker will ensure that the placement of data sections will allow legal accessing beyond the boundaries of the data sections. The linker does this by simply padding the start and end of the memory range(s) where the data sections are placed.

As described in your compiler documentation, please would you check your linker code for that feature. Important for that case is, that no filling section is needed, instaed only a hole without any data should be added. 

For your information. The $fill sections will be triggered by one of my core libraries, which contains extremely optimized code for software define radio (FFT, Viterbi, Reed-Solomon, FIR filter). 

EDIT / Addendum:

The compiler is using the assembler directives Tag_pre_pad_bytes and Tag_post_pad_bytes to inform the linker about needed padding. For example some of the intermediated *.asm files contains the following build attributes (generated by compiler):

	.battr "TI", Tag_File, 1, Tag_pre_pad_bytes(48)
	.battr "TI", Tag_File, 1, Tag_post_pad_bytes(48)

I hope that helps to find the location in your linker code.

Kind regards

Sven

Hi George,

now, with the information from my last post I have found one of the functions which triggers the $fill issue. Attached is a test project. Please, look in the file sources/test_fill.cpp. The function ConvertIntFloat() triggers the generation of build attribute Tag_pre_pad_bytes, which tells the linker to create the $fill sections.

Please, would you fill a bug report, now.

Kind regards

Sven

5241.test.fill.zip