Large 2d array creates invalid cinit

Thijs de Ridder

Our software contains a large 2d array. Because of this array, not all cinit data is loaded to the .bss sections. Below is a description of the problem.

Using: TMS320C55x C/C++ Compiler v4.4.1

problem.c contains only:

char foo[3][0x4100] = {{1},{1},{1}};

cl55 -ss -al -v5502 problem.c

This generates 1 .cinit fields, which contain no data. In the .lst file, 3 .sect ".cinit" are created (I would expect there would be 2 in total).

From the list file:

      35 000000               .sect   ".cinit"
      36                      .align 1
      37 000000 0002          .field          $C$IR_1,16
      38 000001 0000-         .field          _foo+0,24
         000002 0000
      39 000002 0000          .field          0,8
      40 000003 0001          .field 1,16                    ; _foo[0][0] @ 0
      41 000004 0005          .field 5,16                    ; _foo[0][1] @ 16
      42              $C$IR_1:        .set    2
      43
      44 000005               .sect   ".cinit"
      45                      .align 1
      46 000005 0000          .field          $C$IR_2,16
      47 000006 003F-         .field          _foo+16383,24
         000007 FF00
      48 000007 FF00          .field          0,8
      49              $C$IR_2:        .set    0
      50
      51 000008               .sect   ".cinit"
      52                      .align 1
      53 000008 0001          .field          $C$IR_3,16
      54 000009 0041-         .field          _foo+16640,24
         00000a 0000
      55 00000a 0000          .field          0,8
      56 00000b 0001          .field 1,16                    ; _foo[1][0] @ 266240
      57              $C$IR_3:        .set    1

From line 44 to 49 ($C$IR_2), no data is inserted. I experimented with length and data, but the compiler seems always to add this without data. The offset to foo is always 0x3FFF. This offset doesn't change when the size is changed or when more data is inserted.

Run time, this causes a problem with loading the .cinit. From the map file I checked the location of this specific .cinit section. With the debugger, I checked the actual memory. There I discovered that section $C$IR_2 is placed in cinit, but with a length of 0(!). The function which loads cinit (auto_init) stops when it finds a length of 0. This means none of the .cinit after this specific location is loaded.

over 10 years ago

0 George Mock over 10 years ago

TI__Guru**** 244930 points

Thank you for submitting this problem. I can reproduce it. I filed SDSCM00051267 in the SDOWP system to have it addressed. Feel free to follow it with the SDOWP link below in my signature. Since this compiler is not under active development, do not expect a fix in the near future. I filed the problem entry thinking it would help find a workaround.

Thanks and regards,

-George

0 Archaeologist over 10 years ago in reply to George Mock

TI__Guru* 84225 points

The best workaround here is to avoid the static initialization. Put the initializer in a function like so:

init()
{
    foo[0][0] = 1;
    foo[1][0] = 1;
    foo[2][0] = 1;
}

Otherwise, you'd have to resort to manually editing the compiler-generated assembly to fix the .cinit records, and that's a big pain.

0 Thijs de Ridder over 10 years ago in reply to Archaeologist

Prodigy 20 points

Thanks George and Archaeologist. We already came up with the solution of George. We will implement that.

Hopefully it will be fixed some time.

Code Composer Studio™︎

Code Composer Studio forum

Large 2d array creates invalid cinit