Compiler/TMS320C6457: boot code, with binit table, no longer works when migrated from CGT 7.3.1 to 7.3.23

For posterity, here is a another discussion of these symbols:

https://e2e.ti.com/support/development_tools/compiler/f/343/t/561712

These symbols are all part of what we call ".cinit initialization," which handles C and C++ variable initialization before main.  If you don't have any global variables in your program, you don't need .cinit initialization, so in ELF these symbols are left undefined.  There are weak references to these symbols in the startup code (_c_int00 or boot.asm).  If you had needed .cinit initialization, these symbols would have had regular addresses, the weak references would be populated with those addresses, and all proceeds as expected.  Because you don't need .cinit initialization, these weak references are filled with the value 0.  The code in boot.asm checks for the value 0; if the value is 0, no .cinit initialization is performed. 

If you do have some global variables, and yet these symbols remain undefined, that is a bug.  However, if you do not have global variables, it is not a bug for these symbols to show up in the linker map file as undefined.

1. Are you getting any linker error or warning messages?
2. Are you using EABI for both 7.3.13 and 7.3.23?
3. Are your compilation flags identical between 7.3.13 and 7.3.23?

Some targets, such as C6000, support the BINIT routine directly during startup (see _auto_init_elf in autoinit.c).  All you have to do is create a copy table in the linker command file named BINIT.  Is this the support you are using when you say "Our bootloader operates by creating its own binit table," or is this a different process?  For the built-in support, BINIT is handed by _auto_init_elf, just like .cinit initialization.

It makes some sense that one might affect the other, but I'm not seeing anything in the RTS source code that would stop BINIT from working if .cinit initialization was not needed.  The design of boot.c and autoinit.c was changed between 7.3.13 and 7.3.23 to fix a bug, but I don't see anything in those changes that would cause a problem.

Could you please disassemble your 7.3.13 (working/before) and 7.3.23 (failing/after) executables and show me the disassembly of at least function _auto_init_elf?  I'd also like to see your linker map files for the working/failing versions.

Linker map  file

.binit     0    b0001418    00000028    

                  b0001418    00000028     (.binit)

binit disassembly (good on left, bad on right)

There are no differences other than the BINIT table. 

1. No.
2. EABI for both. No changes in project setttings were done.
3. Yes.
I didn't mean to suggest I had changed any code, project settings, or linker command file changes.

I do see the changes you referred to in the RTS lib for C66 (stack setup) and another. __TI_EABI__ should be defined as well.

I did a side experiment. I built with 7.3.1 compiler tools, but pointed to the 7.3.23 RTS lib (big endian, elf). The boot loader booted normally. Correct me if I'm wrong, but this implies the RTS lib changes would not be the culprit.

The problem would show up in function copy_in.  For EABI, in the function copy_in, if __TI_Handler_Table_Base has a definition (it does not in your case), copy_in may attempt to use decompression when copying blocks (including functions).  My thinking was that if .cinit initialization were not used, and BINIT attempted to use compression, that copy_in would do nothing because __TI_Handler_Table_Base was 0.  The BINIT table seems to use no compression by default.  If you use the option --copy_compression=rle (for instance), you change the BINIT table to use RLE compression, but the linker (correctly) provides a definition of __TI_Handler_Table_Base and __TI_Handler_Table_Limit in that case.  So, I still can't create a test case that demonstrates a problem.

To check if you are having the problem I hypothesize above:

1. Look for the section "LINKER GENERATED COPY TABLES" in your linker map file.  You should find a binit table, and it should say compression=none or something like that.  What compression is it actually using?
2. Check the disassembly of function copy_in for MVK/MVKH pairs.  There should be one each for __TI_Handler_Table_Base and __TI_Handler_Table_Limit.  If either of these is 0, you cannot have a binit table with anything but compression=none

Please show me the entire contents of the "LINKER GENERATED COPY TABLES" section. 

Also please show me your full command-line options; it's easiest to get this from the build console window.

1. LINKER GENERATED COPY TABLES

binit @ b0001474 records: 3, size/record: 12, table size: 40
.text: load addr=b00005e0, load size=00000a80, run addr=009e6000, run size=00000a80, compression=none
.const: load addr=b0001060, load size=00000400, run addr=009e6a80, run size=00000400, compression=none
.fardata: load addr=b0001460, load size=00000014, run addr=009e6e80, run size=00000014, compression=none

2. compression is none,
But one of the pairs is 0. I don't see a 2nd mvk with absolute values.

b00003c0 92000029 || [!A1] MVK.S1 0x0000,A4
b00003c4 03900fd8 || MV.L1 A4,A7
b00003c8 92000068 [!A1] MVKH.S1 0x0000,A4
b00003cc 90900264 [!A1] LDW.D1T1 *+A4[0],A1
b00003d0 62c6 MV.L1 A5,A3
b00003d2 0c6e NOP 1
b00003d4 00002000 NOP 2

3.  -mv64+ -g --gcc --define=C6457 --display_error_number --diag_warning=225 --big_endian --abi=eabi -z -m"bootloader.map" --warn_sections -i"C:/CCS_51/ccsv5/doc/7.3.6/lib" -i"C:/CCS_51/ccsv5/doc/7.3.6/include" --reread_libs --rom_model

Hello Archaeologist,

I've narrowed down the versions that work/don't work.

7.3.22, boots up normally.
7.3.23, does not boot up properly, corrupts processor/jtag connectivity, etc. 
 
 The only difference between 7.3.22 and 7.3.23  in the CGT folder is "cg6x.exe".

Also, my binit table starts 4 bytes later in memory in the 7.3.23 version (for clarity, this is the one that doesn't work), as seen below.

The auto_init_elf function disassembly shows it properly handles the change, as shown here:

7.3.22                                       7.3.23

MVK.S1    0x1494, A4              MVK.S1    0x1498, A4

Any thoughts? Any defects or alignment/fill changes in between the compiler releases that might have caused a bump for the start of the binit table?  There are no other changes in the disassembly between the two files, so I am seeing "beneath the hood" as far as I can go.  The binit table is 0x28 bytes in both cases.   The triplet pairs in the table are the same too  (start, destination size).   Again, the disassembly between the two files only shows a binit change; that is, no source code compiler/optimizer rearrangements in main or other function, etc.
 
Thanks,

Will

Archaeologist and team,

We were actually trying to get away from a binary creation issue with ASLR in Windows, fixed in CGT  7.3.13.  

If this isn't a compiler issue, please let me know what else you would like to try...or if there is something I can do to provide more data about the bug, short of sending the project and source, let me know. 

 I'm going to document the two features we should be aware of if we don't use CGT 7.3.23, recommend migrating to CGT  7.3.22 (vs.. CGT  7.3.23) to my team and move forward on integration and testing with that release. 

 
Thanks

-------------------------------------------------------------------------------
FIXED SDSCM00047263
-------------------------------------------------------------------------------

Summary : different binaries after compilation

Fixed in : 7.3.13
Severity : S2 - Major
Affected Component : C/C++ Compiler (cl)

Release Notes:
When address-space layout randomisation is used by the OS, as is usually
the case for modern Windows and Linux versions, compiler output may be
different once in a while on the same input. It isn't predictable; in
the given test case, usually only a handful of iterations are needed
before a difference appears, but sometimes it takes a couple dozen.

Defect occurs in C6000 Compiler versions: 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.12,
7.4.0B1 - 7.4.3

Workaround:
"setarch -R" appears to work around the problem on Linux. There are
apparently add-on tools for Windows that accomplish the same, or one can
fiddle with the registry, but I don't have details.

I just did a source code comparison; there are no differences in the RTS source code between 7.2.22 and 7.2.23.  The only changes in the tools themselves are fixes for SDSCM00051866, SDSCM00051867, and SDSCM00051762, none of which should affect you.  I'm at a loss to point to a change in the compiler.

ixworks said:

The only difference between 7.3.22 and 7.3.23  in the CGT folder is "cg6x.exe".

Hmm, that shouldn't be possible.  Every executable should differ, at the very least by the version number reported.  Please open a command window to the directory where the compilier is installed and type this:

cl6x -version

You should get one line per tool that looks something like this:

TMS320C6x C/C++ Compiler                v7.3.22
Build Number 1PDOQ-0QRTSXTX-UARAR-TAQ-ZAZG_X_T_SS
TMS320C6x C/C++ Parser                  v7.3.22
Build Number 1PDOQ-0QRTSXTX-UARAR-TAQ-ZAZG_X_T_SS
TMS320C6x EABI C/C++ Parser             v7.3.22
Build Number 1PDOQ-0QRTSXTX-UARAR-TAQ-ZAZG_X_T_SS

If each tool doesn't say 7.3.22 or 7.3.23 as expected, please post the result.

If you want to make sure you've got the pristine executables for each version, here are the MD5 checksums:

C6000 7.3.22 (Windows)

205efb2d7fda752add77c67a2d75f483  abs6x.exe
169dbc42f24fe263a13c00a891becbfa  acp6x.exe
80ee142a21f6f690d93eba16452c78fa  acpia6x.exe
27d675f3ca2449f34cac2685d2b8f186  ap6x.exe
dd85c4cd388110cfa3c6edd6a1bb3775  ap6x3.exe
80f826b17be632cfb7eb70b66f9ed992  ar6x.exe
3da69f72cc81681cc4d043a09a180677  asm6x.exe
812b2f7f60b7d3b1e1948c6df10492e4  cg6x.exe
6b3ed9c994782e1677793a00a493e61e  cg6x3.exe
00c49b78ba37397f9ac3937836459993  ci6x.exe
2d19f2aa50993c1545d5932b3214a77b  cl6x.exe
c46fbe93445b722e75b0784a83270cf6  clist6x.exe
022b36095988e9a9d47bedcaff5a00dc  clt6x.exe
7ebcb92c44cce6647722752aae3801d4  cmp6x.exe
3a97956cf17234ea860709b1442dddb0  dem6x.exe
484ce5cbebe31bbc695e3e9d1dabaeee  dis6x.exe
77cd99d5740342ca5724f1a1254d4303  embed6x.exe
fc1de6946ffce35e45372426b936bbc8  hex6x.exe
ed00b24cf11431a1ab188ccc30079ace  ilk6x.exe
200b295880f6d020b0bbbb451fe22758  libinfo6x.exe
fa0a28396d0e920bce22e20990d1151a  lnk6x.exe
0fc0fdb47e254f1b31269ca2e2033477  mk6x.exe
da488138cbf66bce9f6522cc1cb52ef3  nm6x.exe
46dcd58d580b785d84c44414e69d3829  ofd6x.exe
9b2b8820d8e9feeb6f31695c072480f5  opt6x.exe
65bca1bccff7b8fb38797d2381993f65  pdd6x.exe
df2407a50ae257579f00691b4b13f572  pprof6x.exe
98c398f52503a8dad3453fefe624bce1  prelink6x.exe
09bd7af22637be39bd65faeecde12fd8  strip6x.exe
e40d0f68aa6b5931465b2fbc8fcee0ca  xref6x.exe

C6000 7.3.23 (Windows)

767d04cec95bb5ab2a191103424dd943  abs6x.exe
fe3e623fa4d65a4ac3be3356262b3cbc  acp6x.exe
01e5df856593a1d6f5a90ed8fab2d92c  acpia6x.exe
be12de0bf5379d4802f4faf22316e824  ap6x.exe
79d096d863713765fca50ff804ce9a07  ap6x3.exe
c480255c5f45aeccd707438256154026  ar6x.exe
92e619c875e2451be8546dcbed880cc2  asm6x.exe
31a56b468353245f7a157be63b1dbcb6  cg6x.exe
cd20963bd5dfe12d2f6f55abf3e93c6a  cg6x3.exe
41c50caec82089afbad755a4847956a6  ci6x.exe
dbeaec67f0a6a584033340e8e6ec0789  cl6x.exe
e05f32c887a844be80b6662c75153784  clist6x.exe
09de4c737a2696c14f2e89faddf09e7c  clt6x.exe
0cfeafe7d20f8c748bf3eba6fde84083  cmp6x.exe
02267e82d17b6100307063a38b397e5d  dem6x.exe
8510283c570fbb73127c6e7acb3e3a6a  dis6x.exe
c896a784c98c9b5089c4c8896496b48a  embed6x.exe
9753d3b779324395700f2bcbf3b78b11  hex6x.exe
9ee91a09382e1021e38489797a6b7529  ilk6x.exe
53f0425ef958a89e60545a32cbf938f6  libinfo6x.exe
7c4e1eb730ff1b631fc397d1b52f9333  lnk6x.exe
a0e49bce9daa94f1a6a77ecaa304cf09  mk6x.exe
048003fbf6ba999cce2c4435659d750e  nm6x.exe
42228bda6effc2f05c05ad3c9391828b  ofd6x.exe
d6365ad44481b2e2ce02d342405b640d  opt6x.exe
5a3e8aa7729f63630545d7546d900ad6  pdd6x.exe
d13d9048bbecc97280c9d06d5950ae95  pprof6x.exe
93fd5e6f62d66b5d390917ce0b8cfcf6  prelink6x.exe
31e8678f70fc8ef8e03443a3ff3fbfaf  strip6x.exe
e1427eb7b53b457592a8624512d71c9a  xref6x.exe

[Edit: mistakenly posted Linux checksums; changed to Windows checksums -- Archaeologist]

Okay, let's start at the beginning.  You say "Our bootloader operates by creating its own binit table, and executes some code from flash first, before continuing.  The first address is a jump over 256 bytes to clear our metadata (header), and c_int00 starts execution at offset 0x100."  I would like to make sure I really understand what you're saying before I start to suggest steps to debug it. 

Here is the sequence of events I think your program takes.  Please correct me if I am mistaken.

1. The entire program is loaded into FLASH.
2. Execution does not begin at _c_int00, it begins at address 0.
3. At address 0, you have a "header" which is an opcode 0x0040A120 to branch to address 0x100, which is the address of _c_int00
4. _c_int00 invokes the BINIT routine, which copies some functions to RAM. It is this copy which apparently fails.

I note that opcode 0x0040_A120 is actually "BNOP.S1 PC+0x100,5"; PC is the address of the fetch packet, not the address of the BNOP instruction.  If the address of the destination changes a little, you might need to adjust the opcode to branch to the correct address.  Rather than having an opcode for your FLASH header, you might consider making it a one-word code fragment as follows, and let the linker relocate it as necessary:

.ref _c_int00

BNOP _c_int00, 5

You are right. I ran a few of those tools who don't understand -v or -version (or --version). All of the ones that did understand reported 7.3.23. Beyond compare, or user-error, was helping me out by telling me only one executable had changed (in size).

Would it be worthwhile to widdle down which CGT executables cause my problem? e.g., a franken-monster CGT folder with 7.3.23 compiler and 7.3.22 linker. I don't know if your toolset has dependencies that would even make this idea possible.

By the way, my defect history text file only shows two defects fixed in 7.3.23;  both compiler fixes, with one for the delete[] operator and the other related to software pipelining.  *762 shows up in my 7.3.22 fixes, as a linker fix, for dot expressions/align64 creates hugely incorrect size.

I'll be on holiday starting today, so I wont get a chance to test out any thing else until next year, as I'm currently working a separate 1-day task due to personnel shortage.

Thanks,
Will

Happy New Year Archeologist,

The output from that command agrees for each component it reports from the 1st( Parser) to the last (Archiver).  There were 21 total component/CGtool outputs.

------------------------------------------------------------------------------------------------------

TMS320C6x    Tool name         v7.3.23

Build Number 1PEIM-KDADEMDK-RTARQ-WAR-ZAZG-X-T-ST

------------------------------------------------------------------------------------------------------

Please verify these are correct for 7.3.23

Thanks

P.S. here are the checksums for 7.3.23.  From a quick check, I've ensured we match for each (only using the first 3 alphanumeric characters)

//
// File Checksum Integrity Verifier version 2.05.
//
767d04cec95bb5ab2a191103424dd943 c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\abs6x.exe
fe3e623fa4d65a4ac3be3356262b3cbc c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\acp6x.exe
01e5df856593a1d6f5a90ed8fab2d92c c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\acpia6x.exe
be12de0bf5379d4802f4faf22316e824 c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\ap6x.exe
79d096d863713765fca50ff804ce9a07 c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\ap6x3.exe
c480255c5f45aeccd707438256154026 c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\ar6x.exe
92e619c875e2451be8546dcbed880cc2 c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\asm6x.exe
81c178dab60708ea2b5acc97e2f55d61 c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\bti6000.dll
31a56b468353245f7a157be63b1dbcb6 c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\cg6x.exe
cd20963bd5dfe12d2f6f55abf3e93c6a c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\cg6x3.exe
41c50caec82089afbad755a4847956a6 c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\ci6x.exe
dbeaec67f0a6a584033340e8e6ec0789 c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\cl6x.exe
e05f32c887a844be80b6662c75153784 c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\clist6x.exe
09de4c737a2696c14f2e89faddf09e7c c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\clt6x.exe
0cfeafe7d20f8c748bf3eba6fde84083 c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\cmp6x.exe
02267e82d17b6100307063a38b397e5d c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\dem6x.exe
8510283c570fbb73127c6e7acb3e3a6a c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\dis6x.exe
c896a784c98c9b5089c4c8896496b48a c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\embed6x.exe
9753d3b779324395700f2bcbf3b78b11 c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\hex6x.exe
9ee91a09382e1021e38489797a6b7529 c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\ilk6x.exe
53f0425ef958a89e60545a32cbf938f6 c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\libinfo6x.ex
7c4e1eb730ff1b631fc397d1b52f9333 c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\lnk6x.exe
a0e49bce9daa94f1a6a77ecaa304cf09 c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\mk6x.exe
048003fbf6ba999cce2c4435659d750e c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\nm6x.exe
42228bda6effc2f05c05ad3c9391828b c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\ofd6x.exe
d6365ad44481b2e2ce02d342405b640d c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\opt6x.exe
5a3e8aa7729f63630545d7546d900ad6 c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\pdd6x.exe
d13d9048bbecc97280c9d06d5950ae95 c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\pprof6x.exe
93fd5e6f62d66b5d390917ce0b8cfcf6 c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\prelink6x.ex
31e8678f70fc8ef8e03443a3ff3fbfaf c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\strip6x.exe
e1427eb7b53b457592a8624512d71c9a c:\ccs_51\ccsv5\tools\compiler\7.3.23\bin\xref6x.exe

- end checksum

would the binit table start address offset from the .fardata section matter?  That's the only difference I see between 7.3.22 and 7.3.23.  

Update:  The other interesting tidbit;  the compiler doesn't warn me in 7.3.22 if I specifically place binit at 0xB0001414 (which it places there anyways).  However, if I explicitly do this in my linker command file for 7.3.23, it states the binit table MUST be 8 byte aligned for start.  Then, it places a hole at the start of the binit.   Another test with 7.3.22, place the binit table at 0xb0001416 resulted in a warning that the binit table was not 4 byte aligned.  Were there any changes to the linker tool in between these versions that would explain the two size-different alignment warnings?

7.3.22  

.fardata 0    .....  ....   RUN_ADDR  = 0x....

       ....

        ....

       0xB000140c           00000008         : _lock.obj (.fardata)

.binit     0xB0001414  ....   0x28

7.3.23

.fardata 0    .....  ....   RUN_ADDR  = 0x....

       ....

        ....

       0xB000140c           00000008         : _lock.obj (.fardata)

.binit     0xB0001418  ....   0x28

The point I am poorly conveying is there is 8 bytes offset from .fardata to the binit table in 7.3.22, and 12 bytes in 7.3.23.  The end of the _lock.obj lines up exactly with the start of the binit in 7.3.22, but not 7.3.23.  I checked on the function itself, dis6x'ing it in both toolsets (using their respective toolset version), and see no difference in the _lock/_unlock call (which translates to the _nop) call. 

Thanks