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

Sven Mulka

Expert 1162 points

Part Number: TMS320C6657

Tool/software: TI C/C++ Compiler

Dear TI Support Team,

I am using the C66xx linker version v8.2.3.

I found an issue around the automatic generated $fill sections.

I am working with OpenMP and need some non cachable memory inside of MSMCSRAM, for example:

MEMORY
{
	L2SRAM (RWX)		: org = 0x0080.0000, len = 0x0008.0000	// 512 kByte
	MSMCSRAM (RWX)		: org = 0x0c02.0000, len = 0x000e.0000	// 896 kByte
	OMP_MSMC_NC_PHY (RW)	: org = 0x0c00.0000, len = 0x0002.0000	// 128 kByte
	OMP_MSMC_NC_VIRT (RWX)	: org = 0xa000.0000, len = 0x0002.0000	// 128 kByte
	DDR3 (RWX)		: org = 0x8000.0000, len = 0x1f80.0000	// 248 MByte
	DDR3_LOCAL_PHY (RW)	: org = 0x9f80.0000, len = 0x0080.0000	//   8 MByte
	DDR3_LOCAL_VIRT (RW)	: org = 0xb000.0000, len = 0x0040.0000	//   4 MByte
}

The OpenMP secific sections are something like that:

SECTIONS
{
    .tomp_svNcMem:     load= OMP_MSMC_NC_PHY, run= OMP_MSMC_NC_VIRT, fill = 0x0
    .tomp_gvMem:       load= L2SRAM, fill = 0x0
    .tomp_svMemSlow:   load= DDR3
}

Critical is the section .tomp_svNcMem, which is using different load and run addresses. The linker generates a $fill section located before the .tomp_svNcMem section, however the load address will be equal as the run address. At boot time the run address will be not available for the RBL, so that the RBL will write the $fill section to DDR3 and owerride other sections.

I have found a workaround, where I am using "--exclude=$fill*" parameter for the Hex6x tool.

Around that issue I have some questions:

Please, would you confirm that here is a bug in the linker v8.2.3.
What is the reason of the $fill sections?

Thanks and kind regards

Sven

over 6 years ago

0 Cvetolin Shulev-XID over 6 years ago

TI__Guru 65405 points

The team is notified. They will post their feedback directly here.

BR
Tsvetolin Shulev

0 Sven Mulka over 6 years ago in reply to Cvetolin Shulev-XID

Expert 1162 points

Please, would you retrigger the compiler team, because the feedback is missing.

Thanks
Sven

0 Garrett Ding over 6 years ago in reply to Sven Mulka

TI__Mastermind 43296 points

Hi Sven,

Would it be possible that you can share the project (ccs based or makefile) to demonstrate the $fill issue?

The C6x CGT version is v8.2.2 from the latest Processor SDK v4.3, do you also observe the same issue?

Regards,
Garrett

0 Sven Mulka over 6 years ago in reply to Garrett Ding

Expert 1162 points

Dear Garrett,

thanks for your message. I have tried to extract a test project. But I can not trigger the linker behaviour in the test project, the linker do not generate any $fill section. Previously, I thought it had something to do with the "Minimum required memory pad" of some optimized functions, so I had used such private function, but no success.

The origin project is very large and it includes some own IP, which I can not share.

It looks so that the $fill sections are placed at the beginning of each used MEMORY block. The size of generated $fill sektion is different, sometimes 0x80 and 0x30.

Please, would you ask someone from the compiler team, how to trigger the generation of $fill sections?

PS: I am using the latest SDK 4.3.0.5 and before the compiler v8.2.2 has the same behaviour.

Thanks and kind regards
Sven

0 Garrett Ding over 6 years ago in reply to Sven Mulka

TI__Mastermind 43296 points

Sven,

I have reached out compiler team, will update here asap.

Regards,
Garrett

0 George Mock over 6 years ago

TI__Guru**** 241725 points

Sven Mulka said:
The linker generates a $fill section located before the .tomp_svNcMem section

That's confusing. The linker automatically creates such a section only when the fill parameter is used in the MEMORY directive, on a memory range. Using the fill parameter in the SECTIONS directive, on an output section, does not cause a $fill section to be automatically created. Yet I do not see use of the fill parameter anywhere in the MEMORY directive. Are you showing the entire MEMORY directive? Could there be a another linker command file with a MEMORY directive in it?

Thanks and regards,

-George

0 Sven Mulka over 6 years ago in reply to George Mock

Expert 1162 points

Dear George,

thanks for your reply. No, that is not confusing. I have double check the generated linker.cmd file and my own app.cmd file as well. The only place of MEMORY directive is in the linker.cmd file and it does not contain any fill parameter at this MEMORY directive.

I have taken some more tests and I find out that the $fill sections will be generated by the linker in case that the compiler is using the option:

--speculate_loads=auto

Then I was playing with

--speculate_loads=0

and

--speculate_loads=1024

In both cases no $fill section will be add to the linker output anymore.

If I understood the --speculate_loads=auto option correctly, then the compiler signalled the required memory pad to the linker and the linker adds the $fill sections, see SPRUI04B section 4.2.3.2:

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.

Instead, the speculated load will be disabled by --speculate_loads=0.

In case of --speculate_loads=1024 the user must be sure that no access before and after the requested memory will be done, because the linker does not add any $fill sections.

Please, would you confirm my explanations.

Thanks and kind regards

Sven

0 George Mock over 6 years ago in reply to Sven Mulka

TI__Guru**** 241725 points

Sven Mulka said:
Please, would you confirm my explanations.

You are correct. The key thing to understand is the linker adds the additional fill sections only when --speculate_loads=auto is used.

Thanks and regards,

-George

0 Sven Mulka over 6 years ago in reply to George Mock

Expert 1162 points

Dear Georg,

thanks for confirmation.

Please, would you confirm, that the automatic generation of $fill section is wrong (means bug of linker) in case that the load and run address is different for the triggered section / memory definition as descriped in my origin post.

Please, would you fill a SDOWP to track the issue.

Kind regards

Sven

0 Sven Mulka over 6 years ago in reply to Sven Mulka

Expert 1162 points

Hi Georg,

do you have more information to my bug-report?

Kind regards
Sven

0 George Mock over 6 years ago in reply to Sven Mulka

TI__Guru**** 241725 points

Somehow, there are two threads on this topic. Please look for resolution in the other thread. To avoid confusion about which thread to watch, I will mark this one resolved.

Thanks and regards,

-George

Processors

Processors forum

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