Compiler/C64XPLUSCODECS: TI_CINIT_Base UNDEF after migrating CGT from 7.3.1 to 7.3.23

thanks---still requesting assistance. 

I don't understand how this might have happened.  We need a test case which allows us to reproduce it.  Please submit your CCS project as described in this post.

Thanks and regards,

-George

Hi George,
Thanks for your reply. I'm getting approval on what I can and can't share. For now, I can tell you how I generated "A" _TI_INITARRAY_Base and __TI_INITARRAY_Limit issue.

1. I created a new HelloWorld project from "File->New->CCS Project".

2. Then in the project settings, I used C64x+ and EABI format.

No linker command file was specified (unlike my current project), which prsents the .stack and .sysmem warnings. 

3. I built the file, looked at the memory map and see the _TI_INITARRAY_Base and Limit to be "UNDEFED".

How does that happen?

ixworks said:

1. I created a new HelloWorld project from "File->New->CCS Project".

2. Then in the project settings, I used C64x+ and EABI format.

No linker command file was specified (unlike my current project), which prsents the .stack and .sysmem warnings. 

3. I built the file, looked at the memory map and see the _TI_INITARRAY_Base and Limit to be "UNDEFED".

How does that happen?

Suppose you have a C++ class with a non-trivial constructor ...

class ntc          // class with non-trival constructor
{
   int member;
public:
   ntc(int arg);   // constructor defined elsewhere
};

And then you define and initialize a global instance of that class ...

class ntc global_instance(10);

The compiler implements that by creating a function which calls the non-trivial constructor to initialize global_instance with the value 10.  A pointer to this function is added to the section .init_array.  The linker collects all of the .init_array sections from all the files together into one output section also called .init_array.  The symbols __TI_INITARRAY_Base and __TI_INITARRAY_Limit have the start and end address of the .init_array output section.  Startup code in the compiler RTS library uses those symbols to call all of the functions in .init_array.

If your system is has no C++ code, or that C++ code has no instances of global objects with non-trivial constructors, then .init_array is empty and the symbols __TI_INITARRAY_Base and __TI_INITARRAY_Limit are undefined.

Thanks and regards,

-George

George, et al. 

Would you expect it to go from Defined and a non-zero address to "UNDEFED" and 0 when I migrated from 7.3.1 to 7.3.23?

Will

More info...When I step through the code of the errant build, I see a lot of non-aligned loads and stores. Followed by a statement for spkernel 0,0. I have optimization off.  (follow up - these are from memcpy64 - not a problem)
 
Is there something that I should set when I move from 7.3.1, to 7.3.23?

ixworks said:

When I step through the code of the errant build, I see a lot of non-aligned loads and stores. Followed by a statement for spkernel 0,0.

One guess ... The code somehow branched into a memory region that contains data, and not code.  

Thanks and regards,

-George

All of the variables listed above do not show up in the ("working") memory map (just to clarify..."in global symbols") when I build with version 7.3.1.

The common denominator I suppose, would be ".cinit" shows up in the SECTION ALLOCATION MAP as "uninitialized". 

My flags set:

-mv64+  -g --define=C6457 --display_error_number --diag_warning=225 --big_endian --abi=eabi -z -m"bootloader.map" --warn_sections -i"C:\CCS51\ccsv5\tools\compiler\7.3.23\lib" -i"C:\CCS51\ccsv5\tools\compiler\7.3.23\include" --reread_libs --rom_model

ixworks said:

3. I built the file, looked at the memory map and see the _TI_INITARRAY_Base and Limit to be "UNDEFED".

How does that happen?

These two symbols (__TI_INITARRAY_Base and __TI_INITARRAY_Limit) are only used for C++ programs, so they are left undefined by the linker.  These symbols have a weak reference in RTS file autoinit.asm; because they are undefined, they get the value 0.  This is all as designed, and is not an error.

ixworks said:

I'm getting 6 UNDEFED's that were not there in my 7.3.1 CGT tools. 

When you say this, do you mean the only symptom is that you have these extra symbols in your linker map?  That is not an error, that is by design.

I had though you mean that you were also getting a linker error to the effect "undefined symbol __TI_CINIT_Base", but now that I look at the thread as a whole, I now think I was mistaken in that assumption.

All six of these symbols have weak references in the RTS code so that we can simplify the RTS code.  The linker defines these symbols only if needed, and if you don't have any global variables, there is no need to define these symbols.  Nonetheless, the weak references must still be resolved, so they show up in the linker map file.

ixworks said:

Here's something unique to our project; we'd like to have a header attached to the beginning of the ROM image for the bootloader. This means the first 32-bits must be an opcode jump over to 0x100 offset in flash.

We lack expertise in system startup issues like this.  I recommend you start a new thread in the C64x device forum.  Or, if you prefer, I can move this post into a new thread in that forum.  

Thanks and regards,

-George