TMS320F280039C: TMS320F280039: new project compiler error for LFU application

Yuan,

I'm in the process of creating a bug for tracking this issue but having issues reproducing. 

For the linker error 10478 issue, are the two instances of same-name static variable also in two source files with same file names but just different folders?
Or are the same-name static variables in two different source files with different file names?

Regarding workaround, you can either rename one of the variables to avoid the duplicate output.
Or mark one variable with __attribute__((update)).  However, this means the variable will not be preserved and will instead be moved to the .TI.update section.  Depending on the variable's state at lfu warm switchover, you might need to manually update it after the call to __TI_auto_init_warm() which would only do the initialization based on source code value and not the latest runtime value..  

NOTE: I can only reproduce the issue for the case of same-name-static variable in two same-name-files. And if that's the case you have then it's already something lfu cannot support since the current implementation cannot distinguish between each same-name-file's compile as to which address it matches in the reference executable.  It should emit a warning like below:

warning #30017-D: For lfu compile of "test1.c", the reference executable's
symbol table has multiple file entries with same file name. If two same-name
files have duplicate-same-name static variables that are lfu "preserved",
then the compiler will assign both static variables with the same address.
This could result in linker placement errors.

HI GregM,

The same-name static variables in two different source files with different file names.

We define static  TIMETICK_VAR_T      *s_pTimeTickVar in the 1.c file     s_pTimeTickVar   = &g_tTimeTickVar;

and define static  TIMETICK_VAR_T      *s_pTimeTickVar in the 2.c file    s_pTimeTickVar   = &g_tTimeTickVar;

and define  static  TIMETICK_VAR_T      *s_pTimeTickVar in the 3.c file   s_pTimeTickVar   = &g_tTimeTickVar;

...

and define extern TIMETICK_VAR_T      g_tTimeTickVar in the 12.c file.

We will adopt this approach to reference global variables defined in a specific file across different .c source files.Therefore, we cannot easily modify a certain variable, as it is referenced in numerous places. Moreover, these variables should be preserved during the LFU process.

......

Yuan,

Are you able to share your linker map file for the reference executable?  -lfu=ref.out

If I can confirm the layout and location of above variables then there may be a possible workaround by using dummy variables to get the linker to avoid creating duplicate collections which leads to the 10478 error check to avoid creating two same-name collections.

If you would rather send directly to me, I'll send a friend request.

Thanks,
Greg

HI GregM

I’ve asked Terry (FAE) to send you the file via email. Please kindly check your inbox. Thank you!

Yuan,

I've reviewed other work arounds and none have worked even on my simple test case.

I'll send an alpha linker to your FAE so you can test the fix.

Then we can release above in 22.6.4.LTS which should go out in a few weeks.

Regards,
Greg

Hi Greg

Could you please advise when the alpha linker can be sent to the FAE? Without resolving this issue, we are unable to proceed with the debugging of the LFU function.

Yuan,

I just sent to your FAE. I sent an alpha compiler installer for 25.12 (basically 25.11.2.LTS). If that fixes your issue then let me know and we can release the fix in 22.6.4.LTS within a week of your confirmation since I believe you were using 22.6.2.LTS 

Regards,
Greg