C55 linker not completing

Nathan Posey said:

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?

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?

Hi Aarti,

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? 

Hi Nathan,

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,

-George

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.

Thanks and regards,

-George

Nathan,

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,

Todd Snider

Code Generation Tools Group

Texas Instruments Incorporated

Hi Todd,

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.

Nathan,

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:

• the v4.4.1 assembler will emit a warning on the .sym directive that is trying to add debug information about the "_atan2_16_interleaved_spp" symbol to the output file; the warning suggests the use of the --symdebug:coff option, but when I add that option, the v4.4.1 assembler emits a "corrupted object file" error saying that the debug symbols which delimit function and lexical block scopes are not balanced
• the v3.2.2 assembler does not complain and it will encode the incorrect "next" symbol index into the "_atan2_16_interleaved_ssp" symbol's auxiliary entry

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?

- Todd

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.

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.