Include linker command file in 3.3 project imported to CCS5

I would start by comparing the build commands for CCS 3.3 and 5.1.1 specifically the link step. I suspect that in 5.1.1, it may be picking up another linker command file in addition (or in place of) your custom linker command file, or there are multiple files and somehow the link order is affecting the section placement. In CCS 3.3, the link command will be in the file Debug.lkf. In CCS 5.1.1 you can see it in the CCS build console. Try comparing these and see if you can spot a difference.

If you are unable to isolate the reason for the difference, please copy the full output of the CCSv5 build console on to a text file and attach it here. Also attach the link map file generated in CCSv5.

I had a trouble posting on the forum for a week, not it get fixed.

I made a big mistake and updated CGT for my CCS v3.3 and get it broken.So I removed source which was crashing compiler and got some output from 6.0.8 CGT. Linker command line in build option is

-q -c -m"myproject.map" -o"myproject.out" -x -i"%BIOS_INSTALL_DIR%/packages/ti/rtdx/lib/C6000" -l"csl6416.lib"

Excerpt from map file is attached as v6.0.08.map. As one can see, .init_booting, .booting and .info sections contain data in them and allocation is as expected. Also boot_main function, which is expected to be linked in main_boot section is found in symbols list with expected address 0x100.

Now let's see v5.1 output. In attached out7.3.5.txt there is excerpt of output console.Command line follows prescribed pattern

cl6x--run_linker{--rom_model | --ram_model}filenames [options] [--output_file= name.out] --library=library [lnk.cmd]

I see my custom link file is specified as last argument. However, there is -l"myprojectcfg.cmd" option specified before input object files. As I understand, it defines DSP/BIOS stuff linking. If we look inside generated map file (v7.3.5.map), only .prg_info section has correct data, others seems to be unused. Moreover, in the section allocation map we see, that at 0x0 there is unexpected there

.vers      0    00000000    00000038     COPY SECTION.

I know where it comes from. In the above mentioned -l"myprojectcfg.cmd" there is a command

/* MODULE GBL */

SECTIONS {
   .vers (COPY): {} /* version information */
}

So, my trouble is that cmd file of DSP/BIOS is get linked before my custom command file. In the same time, my command file is not processed properly. Function boot_main does not go to expected 0x100, it is not even mentioned in symbols list.

I noticed that this behaviour happen first time when I switched from 6.0.x CGT to 6.1.x. Could you guess, what I missed in my linker command file?

Thanks in advance.

rrlagic said:

So, my trouble is that cmd file of DSP/BIOS is get linked before my custom command file. In the same time, my command file is not processed properly. Function boot_main does not go to expected 0x100, it is not even mentioned in symbols list.

Did you compare the build command line from CCS 5.1 with the one from CCS 3.3? I see that you attached the output build console for CCS 5.1 but not the one from CCS 3.3. The key things to check are whether the same set of files (.obj + .lib) are being passed to the linker and the order of linker command files(if there is more than one).

Another test to perform might be use CGT 6.0.8 with CCSv5.1 and confirm if the map file is as expected. This could help determine if the issue is in the way the project was migrated to CCSv5 (which is what I suspect) or is in the CGT 7.3.x itself. The steps to use a different version of CGT with CCSv5 is documented here.

I have seen in a couple of cases where a CCS 3.3 project migrated to CCSv5 may require the link order of files to be re-specified in order to achieve the desired link result. In CCSv5, you can specify the order in which files are to be linked by going into Project Properties->CCS Build->Link Order tab. Depending on the complexity of the project and the way it was originally set up, the import tool in CCSv5 sometimes does not do a perfect job in the migration, thereby requiring some additional custom modifications to get an equivalent project.

Hello,

Thank you for response. I attach .lkf file of my 3.3 project, there is a command line to linker.

As to 5.1, already I tried 6.0.x CGT. No surprise, with that version of CGT my project is linked correctly. But trouble is that with 6.0.x CGT the RTA does not work. With 7.3.5 I get RTA working, but boot code is missing due to linker issue.

In my 3.3 project I do specify linking order and put my custom linker command file before generated one. I do the same in 5.1, but it does not help. Again, if I try CGT of 6.1.x and above on 3.3, then linking is wrong. So I suspect there was some linker behaviour change between 6.0.x and 6.1.x, which I missed and noticed only on 7.3.5.

Can you suggest, where to look more?

Thanks

Can you attach the 2 linker command files (your custom one and the BIOS generated one) as well as the link map files generated with CGT 6.0.x and 7.3.x? That may give us more clues.

Hello,

I attach two map files, linker command files and makefile found in debug folder of v5.1 project.

Thanks you for assistance.

According to the 6.0.29 map file, the object file booting.obj should have sections .init_booting and .booting. Can you check that those sections exist in the booting.obj file generated with 7.3.x? To do this, you can run ofd6x on the .obj file and check if the output file has these sections. Open a command prompt and run the following:

ofd6x -g booting.obj > booting_ofd.txt

You may need to specify the paths to ofd6x (which is in the \bin folder within the compiler tools directory) and booting.obj. Then open the booting_ofd.txt and check if those sections are present.

If they are, the next thing to try is to add boot.cmd directly to the project instead of lte.cmd which in turn adds boot.cmd, and see if that makes a difference.

Ultimately, it might be easier for us to analyze further if we had the complete project along with all source/object files. Are you able to share the complete project so we can build it at our end?

Try adding these options to the link ...

-u _primary_loader
-u _boot_main

I suspect the linker sees that there are no references to these symbols.  Even though those symbols are defined in sections from the file booting.obj, because there are no references, the linker leaves those sections out.  Using -u forces the linker to refer to those symbols, and thus keep those sections.  

At this point, I'm not sure why the linker is acting this way.  I think this will fix it.  Then we can figure out why.

Thanks and regards,

-George

First of all, thank you for keep helping me with this issue.

I've tried to verify required sections presence in the object file. They are present.

 Section Information                                                    
                                                                        
    id name                      load addr  run addr    size align alloc
    -- ----                      ---------  --------    ---- ----- -----
     1 $build.attributes         0x00000000 0x00000000  0x2a     1   N  
     2 .text                     0x00000000 0x00000000   0x0     1   Y  
     3 .data                     0x00000000 0x00000000   0x0     1   Y  
     4 .bss                      0x00000000 0x00000000   0x0     1   Y  
     5 .debug_info               0x00000000 0x00000000 0xa73     1   N  
     6 .booting                  0x00000000 0x00000000  0x80    32   Y  
     7 .init_booting             0x00000000 0x00000000  0x80    32   Y  
     8 .debug_frame              0x00000000 0x00000000 0x27b     1   N  
     9 .debug_line               0x00000000 0x00000000  0xc9     1   N  
    10 .debug_abbrev             0x00000000 0x00000000  0xc4     1   N  

Then I tried to add -u option to the linker. I attach archive with map file. Better, but not perfect. I don't understand the output clearly, but seems that there is some overlap 0x00. I am doing this with CGT 7.3.5 on CCS5.1. Unfortunately, I cannot compare with CCS3.3 and CGT 6.1.x because of another issue.

As to complete project, I would refrain from publishing it on the web, but I will try to create stripped test project just to illustrate the phenomenon. If we can proceed without it, it would save me some time.

And again, thank you for support.

rrlagic said:

Then I tried to add -u option to the linker. I attach archive with map file. Better, but not perfect. I don't understand the output clearly, but seems that there is some overlap 0x00

OK, so now you do get the .init_booting and .booting sections in the map file. Thanks to George for suggesting the -u option.

The overlap is fine because the .vers and $BRID are marked as COPY sections. A COPY section is not actually loaded to the target memory, so it won't really overlay anything.  More info on COPY sections and other special sections is here: http://processors.wiki.ti.com/index.php/Linker_Special_Section_Types

AartiG, 

You think the issue is resolved? I am using out file to make hex, then bin, burned to the flash. Will check it next week.

And if possible I'd like to find the root cause,why linker was omitting those section. Is -u the only way to get it fixed?

rrlagic said:

You think the issue is resolved? I am using out file to make hex, then bin, burned to the flash. Will check it next week.

And if possible I'd like to find the root cause,why linker was omitting those section. Is -u the only way to get it fixed?

Please let us know when you've had a chance to test out the binary.

Regarding why the linker was removing those sections, we would really need a test case to analyze it further. If you're concerned about posting the complete project here on the forums, you can share it with us privately. Alternately if you can create a stripped down version that demonstrates the problem, that would also work. Please let us know if you'd like to move ahead with either of these options.

Hello AartiG,

I cannot prove binary right now as my unit has hardware problem and now passed to hardware engineer for repair, but definitely I will try and report here.

Definitely, I'd like to find the root cause of linker behaviour and willing to provide required info. As to test case, I'd like to share stripped version but still privately. Please let me know how should I do that.

Thank you for support.

rrlagic said:

As to test case, I'd like to share stripped version but still privately. Please let me know how should I do that.

I sent you a friend request. When you accept you can start a private conversation with me and attach a zip file with the complete project. Please also include any specific directions/instructions that may be required to reproduce the issue.

Thank you for sharing your project with us. I have submitted a bug report for this so the compiler team can further analyze the issue and provide the reason for the different behavior between the older and newer linker. The bug tracking # is SDSCM00044199 and you may track the status of the bug using the SDOWP link in my signature.

For now, I am glad you have been able to use the workaround and move ahead with your development.

Hello AartiG,

Thank you very much for assisting me on this issue. I have checked bug report. I'd like to add, that linker behaviour has changed from 6.0.x to 6.1.x code generation tools. First time I discovered it I just gave up and reverted to 6.0x. I hope this information may help to trace the root cause and probably CGT of 6.1.x branch would be updated too. Also I noticed that platform is described as "C64x Plus C6000", though I met it on C6414/C6416, which is C64x not C64x+. Does that mean any difference?

PS

Is there any way to get e-mail notifications on bug activity?

Yes, the linker behavior changed slightly between 6.0 and 6.1.  Please see the slides at http://processors.wiki.ti.com/index.php/C6x_Code_Generation_Tools_v6.1

Hello!

I got one more observation. Using tricks and magic I have revived my CCSv3.3 installation. I've tried to use -u linker option to specify function names which were omitted by linker. And it did not work for me in CCS 3.3 with CGT 6.1.21. Error message is symbol unresolved. Could you please verify this problem using test case I provided with CGT of 6.1.x branch?

rrlagic said:

I've tried to use -u linker option to specify function names which were omitted by linker. And it did not work for me in CCS 3.3 with CGT 6.1.21.

I tested this with CCS 5.1.1 and CGT 6.1.18 and after adding the -u option, I was able to link without errors and verify that the sections do appear correctly in the link map file. I don't see any reason why it would be any different with CCS 3.3. Are you sure you are specifying the symbol names with an underscore (as in _primary_loader and _boot_main)?

AartiG,

Sorry for making noise, that was my fault. With decorated symbols names its OK.

Mea culpa.