Updating the DSP toolchain from CCS 3.1 to 5.1 and when linking it seems like the lnk55 process just gets stuck and never ends. I have left it linking for about 30 minutes or so. Is there anything I can do to see what it is getting stuck on? The only output the linker has given me is:
warning: section ".memLogSpace" (0x300000) spans page boundary: not allowed before CPU revision 3.0which is fine because we had the same warning with the 3.1 linker. I ran procmon on my computer with lnk55.exe as the process ID filter after I felt like the link had come to a hault and no events were being shown.
I am using the 4.4.1 release of the tools which is the latest. Here is the command line I am running:
lnk55.exe -a -x -priority -w -b -c --issue_remarks --verbose_diagnostics -o output/bin/my_out.out -m output/bin/my_out.map dsp_link.lcf output/lib/main_dsp.lib *many other libs*
What would be a good way to debug this issue? Start backing out libs from my library list? Almost all of the other libs that I am linking in are built with the old tool chain, is that going to be an issue? Thanks for your time and help.
Nathan PoseyWhat would be a good way to debug this issue? Start backing out libs from my library list? Almost all of the other libs that I am linking in are built with the old tool chain, is that going to be an issue?
You could try taking out libraries from the list and see if you can identify one or more that specifically trigger the hang.
Which version of the compiler tools was used to build those libraries? What were the build options used with the old version to generate those libraries, and the compile options with the new version? Are these libraries very large in size?
If a post answers your question please mark it with the "Verify Answer" button
Search the wikis for common questions: CGT, BIOS, CCSv3, CCSv4Track a known bug with SDOWP. Enter the bug id in the "Find Record ID" box
The previous C55 compiler was 3.2.2. I have narrowed the search down from the original 40ish libs to just two which are causing the link to get blocked. Basically if I just try linking in my object library that has been completely built with the new compiler with only these two libraries the linker will grind to a halt. One of the libraries is 19,506KB and the other is 5,205KB so I wouldn't say they are too large.
They are both built with exactly the same compiler flags for every object:
-pdv -pden -qq -ar -ml -g -o3 -vcore:2.1 -eo.obj -DBIG_ENDIAN -DPROCESSOR_ACCESS_SIZE=16
Building them without the -o3 option did not make a difference which is what I was suspicious of. The only other thing that is slightly different about one of these libs is that it builds a few asm files in and they had different build options but I changed those to the same as the other .cpp files (the options above) and there was no change. Is there something else I could try? Is there a debug version of lnk55.exe that I could connect to with microsoft debug tools and get a call stack or something?
Maybe you could try removing the -g option when building those libs? If that does not help, would you be able to share these two libraries and the objects used for the final link so we can reproduce the issue? Then we might be able to get a linker expert to take a look at the files and see if they can determine the reason for the lock up/suggest workarounds. If you do not wish to post the files on the forum, you can send me a friend request and send it to me via private conversation.
unfortunately the removal of the -g option when building those libraries with the older toolchain did not help. I will be sending you the files to reproduce on your end.
Latest update on this:
I cannot duplicate the linker hang using the files provided and command line:lnk55 -a -x -priority -w -b -c --issue_remarks --verbose_diagnostics -o dsp.out -m dsp.map dsp_link.lcf main_dsp.lib LE_TIC55xx_CCS_lib.lib CL_TIC55xx_CCS_lib.lib Nathan's original command involves paths that are over a clearcase MVFS file system on the network. The linker hangs when those paths are present but not when the files are copied to local directory. He will experiment some more and post updates to this thread.
Ok I think the reason your link was completing was because of some errors with the linker file including specific object versions which did not exist for you. Using that little clue though I went into the linker file I sent you and started cleaning out the specific versions of libs and objs in there that were being pointed to. I have eliminated all of them to being a problem case except for one library whose data section is explicitly placed in the linker. With this library available so that the linker can see it the build gets halted. I have just verified that removing -o3 and -g from this library command line still results in the linker to halt. I can send anyone who has time to look at this an updated zip containing all these files. So now the current error case I have down to these 4 libraries and the linker command file and I can recreate this linker halt on the local file system with all files and the linker in the same dir just like you were testing.
I was able to get the link completed by removing the -o3 from any library build that was using and rebuilding the lib with -g. I would really appreciate it if someone at TI could take a look at the files and have someone on the linker team take a look as the why it freezes. Luckily only a couple of the libs use -o3 so working around that for now is not a huge issue but it will be a pain going forward. I know Aarti is out for a few weeks so if someone else could contact to me I can send the files.
Please send the files to me. Click on my screename to bring up my forum profile. Then, near the upper right corner, click on Start Conversation. A dialog for sending me a message comes up. You can send the .zip file as an attachment to that message.
Thank you for your time and patience so far.
Thanks and regards,
TI C/C++ Compiler Forum ModeratorPlease click Verify Answer on the best reply to your question.The Compiler Wiki answers most common questions.Track an issue with SDOWP. Enter your bug id in the "Find Record ID" box.
I can reproduce your issue. I filed SDSCM00044873 in the SDOWP system to have it addressed. Feel free to follow it with the SDOWP link below in my signature.
Thank you again for that test case. I'm sure it was tough putting that together. I tried to find a workaround, but couldn't. We just have to wait for an expert to analyze it further.
I have done some poking around and debugging of the linker using the test case provided with the defect report (SDSCM00044873) and was able to narrow the issue down to an encoding error in the symbol table for the COFF object file 'atan2_16_interleaved.obj' which is a member of 'ssp_dsp_core_c55plusx.lib'.
Specifically, there is a cycle encoded into the symbol table which prevents the linker from progressing through the symbol table while processing it. The specific symbol that is causing the problem is '_atan2_16_interleaved_ssp'. It resides at index '1' in the symbol table, but it has an index of '0' encoded for its next symbol. This causes the linker to spin between index 1 and 0 while processing the symbol table for this file.
I suspect the root of the problem happens while compiling and assembling the source for 'atan2_16_interleaved.obj'. Can you provide the source for 'atan2_16_interleaved.obj' and the compiler options used to build it?
Thanks and Regards,
Code Generation Tools Group
Texas Instruments Incorporated
Thanks for taking a look at this and getting a response back to me so quickly. I have sent the file to Georgem along with the build instructions. It should be simple to build. If there is any more information needed please let me know. As I have stated before it is being built with the 3.2.2 C55 compiler.
I received the source from George and have started looking at the difference between the v3.2.2 and v4.4.1 assemblers behavior vs. latest available release. Here are some observations:
I am still looking at why v4.4.1 generates warnings and errors about the .sym directive, but perhaps a potential workaround is to comment out the .sym directive from the source?
Alright I just tried that, commenting out this line:
; .sym _atan2_16_interleaved_ssp, _atan2_16_interleaved_ssp, 32, 2, 0
The behavior is the same the linker gets jammed. I can send you the obj file or the library if you want with the sym commented out to see if there's any difference. I am guessing the -o3 option that is used to build with is ignored for assembly files and that's why theres debug info in it? Also just from looking at the source in the other asm files that are in that library they all have the same sym format function_name, function_name, 32, 2, 0. I guess it is possible that the linker has correctly matched this obj in the lib and got stuck on the next one. Maybe the real problem is a difference between the sym formats in the two different compilers. Do you have an example one in some C55 assembly that we can compare to? Looking through some of our other C55 libs that use assembly and they do not contain the .sym directive. Reading in the C55 assembly tools the .sym directive is supported so we must be using the wrong format.
Removing the .sym directive from atan2_16_interleaved.asm does fix the index cycle problem in that object file, but it does not fix any instances of the same problem in other object files in the ssp_dsp_core_c55plusx.lib library.
I verified the behavior you see after "repairing" atan2_16_interleaved.obj; the linker still hangs, but it hangs on another object file that has the same symbol table issue, scale_vector.obj. From your above comments, it sounds like you've already figured that out.
The assembler behavior has definitely changed between v3.2.2 and v4.4.1. The change in the handling of the .sym directive occurs with release v3.3.1.
If it is possible to do so, re-building the ssp_dsp_core_c55plusx.lib library with a more recent version ofthe compiler (3.3.1 or higher) in combination with either removing uses of the .sym directive or compiling the library without debug would likely fix the linker issue.
Thanks for figuring this out. I will probably be holding off on upgrading our tool chain for a little bit because of some additional issues that I am tracking down but when the eventual upgrade comes at least this is one problem solved.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.