• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 2550 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler/TMS320C6678: problem with output section ".fardata" compression

Alberto Chessa
Mastermind 6650 points
Part Number: TMS320C6678

Tool/software: TI C/C++ Compiler

Hi,

The linker give me this warning:

"output section ".fardata" refers to load symbol "$C$SL61" and hence cannot be compressed"

Where the problematic symbol come form a library and refer to a literal string used in the initialization of a non-const structure. If I try to remove any reference to the compilation module that embed that string, the warning move to another symbol, always a literal string.

I use the library is a lot of project, including more or less the same object modules and sometimes I get this error, but not always.. So far I was not able to discriminate the difference between the project that generate the problem or not.

My linker command file reord the output section but I have some very similar application (that is they use the same modules from my library) with same section order that don't generate the warning.

CGT: C6000 7.4.21 (but problem present also with older version)

  • 0
    TI__Guru**** 238965 points

    For a full explanation of you situation, see this forum thread.  It is a long read.  Here is what it means in your specific case.

    Keep in mind this is a warning.  The resulting build works.  But it is using up more memory than is ideal.  If you don't care about that, then you can ignore the warning.

    The symbol $C$SL61 is for a string constant in the section .const:.string.  Therefore, the most likely cause of this problem is that the output sections .fardata and .const (or .const:.string) are in the same GROUP.  If that is the case, one solution is to remove .const from the GROUP and allocate it separately.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Mastermind 6650 points
    Hi,

    The .const and .fardata are already in separate group. Since the "offending" symbols should be used only internally by the library, I tried also to isolate library .const and .fardata. The result is that the library .fardata cannot be compressed (as expected) but also the application .fardata cannot be compress as well.

    I looks strange since apparently the application interface with the library only via non-inline function and has not references to the library internal data.

    I suppose there are "hidden" references that escape from my review.
  • 0 in reply to Alberto Chessa
    TI__Guru**** 238965 points

    Alberto Chessa said:
    The .const and .fardata are already in separate group.

    Then I don't understand why you are getting that diagnostic.  Please attach your linker command file to your next post.  So the forum will accept it, add the file extension ".txt" to it.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Mastermind 6650 points

    HI,

    I have some problems attaching the file. Since it is small, I paste it as code:

    #define K(x_)  ((x_)*1024)

#define L2_BASE 0x00800000
#define L2_IBL_RESERVED_SIZE 0x20000
#define L2_SIZE (K(512))
#define L2_RESERVED_SIZE	(K(1))

MEMORY
{
	L2SRAM: o=0x00800000, l=((L2_SIZE-L2_RESERVED_SIZE))
	L2SRAM_RESERVED: o=END(L2SRAM), l=L2_RESERVED_SIZE

	SH_RAM: o=0x0C000000, l=K((4*1024)-64)

	SH_RAM_RESERVED: o=0x0C000000+K((4*1024)-64), l=K(64)

	FLASH: o=0x70000000, l=K(128*1024)

	DDR3_RAM: o=0x80000000, l=K(512*1024)
}

#define CODE_MEM  L2SRAM
#define DATA_MEM  L2SRAM

#define EXTRA_MEM DDR3_RAM

SECTIONS
{
  GROUP(CODE)
  {
    .text
    .const
    .switch

    .cinit: align=0x010	////warning #10229-D: output section ".fardata" refers to load symbol "$C$SL23" and hence cannot be compressed; compression "rle" is ignored

    .app_signature: fill=0x00, align=0x100

  } > CODE_MEM

  GROUP(DATA)
  {
    .data
    .bss
    .rodata
    .neardata

    .far
    .fardata

    .stack: type=NOLOAD
    .sysmem : type=NOLOAD

    
  } > DATA_MEM

  //.cinit: align=0x010 > CODE_MEM	//if .cinit placed here the problem disappear

}

  • 0 in reply to Alberto Chessa
    TI__Guru**** 238965 points

    The problem is that .cinit and .const are in the same GROUP.  Read the section titled Automatic Initialization of Variables in the C6000 compiler manual, and you will learn that the .cinit section is developed by processing the .data, .fardata, and other similar sections that contain initialized global variables.  Recall that .fardata and .const must not be in the same GROUP.  So, this extends the dependence between .fardata and .const to include the section .cinit.

    It bears repeating that the diagnostic is a warning.  It is not an error.  The resulting build works.  But it uses more memory than strictly necessary due to the lack of compression.  If you are meeting your goals with regard to the amount of memory used, then consider ignoring the warning.

    To avoid the warning, the sections .cinit and .const cannot be in the same GROUP.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Mastermind 6650 points
    Hi,

    If I move the .const in another group the problems move to a static initialization of a pointer to function, that is a dependency between .fardata and .text. The pointer definition and the function are both static to the same compilation unit.

    I understand the result build work and so far the size is not a problem. I simple would like to understand why on some other applications the warning is not present, even if they have essentially the same memory layout and that use the same library modules.
    So far I was not able to identify the key difference that generate the warning.
  • 0 in reply to Alberto Chessa
    TI__Guru* 84225 points
    The warning is triggered by the linker realizing it has reached an impossible-to-solve dependence cycle.

    .cinit contains the compressed initial values of initialized sections like .fardata. In order to perform the compression, the
    the size and contents of the compressed section need to be known (aka finalized) beforehand. Suppose a data section A contains a variable which has an initial value that is a pointer to some other section B. Then section A cannot be finalized until the placement of section B is known. This creates an ordering; B must be placed before A is finalized. Now suppose that section A is .cinit, and section B is .fardata, and they are in the same group, with .fardata coming second. Now .cinit cannot be finalized before .fardata is placed, but .fardata cannot be placed until the length of .cinit is known, which cannot be known until .cinit is finalized, which is an impossible cycle. This is just the most trivial example.

    The easiest solution is not to put .cinit in any group. There are other ways to get rid of the warning, but pretty much all of them require detailed knowledge of which sections in your application refer to which other sections, so there really isn't a "one size fits all" answer.