Compiler/TMS320C6678: Linker warning #17003-D when linking with multithread RTS library.

Hello canfoderiskii,

I suspect you have a conflict between where the __errno symbol is defined and where the multi-threaded library thinks it is.

The RTS library source in the C6x CGT v8.1.3 shows the following definition for __errno:

/*---------------------------------------------------------------------------*/
/* The internal implementation of 'errno' is controlled via the __TI_USE_TLS */
/* symbol. For a thread-safe library, __errno will be given a __thread       */
/* qualifier (making it TLS). For non-thread-safe libraries, __errno is      */
/* defined as a scalar int.                                                  */
/*---------------------------------------------------------------------------*/
__TI_TLS_DATA_DEF(extern, int, __errno, 0);

Do you compile an errno.c separately from RTS library? If so, do you compile it with or without --multithread? The multithreaded RTS library assumes that __errno is defined in thread local storage (also referred to as TLS). Each thread is assumed to have their own copy of __errno in a multithreaded application. Consequently, each thread must be responsible for addressing any error codes which come up within the execution of their thread. For example, if an application creates thread X, then any error codes that are set in thread X's copy of __errno must be addressed by the code executing in thread X.

The relocation type "R_C6000_TPR_U15_B" assumes that __errno is defined in a TLS block that is allocated and initialized when the current thread is created. Apparently, __errno is not defined in a TLS block, so the linker is finding its definition at a location that is out of range from the start of the TLS block. Hence, the relocation overflow.

If possible, can you provide a linker generated map file from your above link attempt? It would be useful to know from the map file where the definition of '__errno' or 'errno' is located.

Sincerely,

Todd Snider

Compiler Group

Texas Instruments Incorporated

1. I didn't compile errno.c separately from RTS library, I linked the RTS library shipped with CGT.
2. Here is my .map file:

GPImgProcBrd_test_exec.zip

From the map file, __errno is defined at address 0x008376dc which happens to be the value reported by the relocation overflow warning.

__errno's offset relative to the start of the .tdata section is 0 and that is the value that should have been assigned to the symbol __errno

Note that __TI_TLS_BLOCK_SIZE is 0xffffffff (or -1). This means that for some reason, the linker does not think it is necessary to create a TLS block.

Unfortunately, I can't determine why this is unless I can try to reproduce the behavior of your link attempt.

Could you collect the object files and object libraries that are used as input files to your link and send those along with any linker command files that you may have used and the link command that you used to invoke the link?

If you would be more comfortable providing this information offline, you can send me a friend request via the e2e forum and we will figure out how to move forward.

Regards,

Todd Snider

Hi, Todd.

I solved that problem. I added an extra .cmd file for my SYSBIOS project, in which I added the location definition for 3 sections: .TI.tls, .TI.tls_init, .tdata. Then linking is successfully done.
I remember the linker is able to allocate sections into default MEMORY without any specifition given by user. Why didn't this linker's feature work in this multithread situation?

But, here comes the another problem.Even though I spcified the .tdata section in the .cmd file, I still got a linker warning described below:
warning #10247-D: creating output section ".tdata" without a SECTIONS specification.

I can find .tdata is allocated somewhere in the .map file. This new problem is strange to me.

canfoderiskii said:

Even though I spcified the .tdata section in the .cmd file, I still got a linker warning

In your next post, please attach the linker command file that specifies the .tdata output section.  So the forum will accept it, add the file extension .txt.

Thanks and regards,

-George

The added extra linker .cmd file is simple:

SECTIONS
{
    .TI.tls > L2SRAM
    .TI.tls_init > L2SRAM
    .tdata > L2SRAM
}

Hi Canfoderiskii,

I agree that the linker should not be generating a warning about creating a .tdata output section when you've clearly got one already in the linker command file.

Is the .tdata output section at least being placed within the L2SRAM memory area as you requested? If not, then there is something wrong in the handling of the .tdata output section specification in the linker's parsing of the linker command file.

I will try to duplicate the warning behavior with a couple of example test cases to see if I can determine the root of the problem. If I can't reproduce the linker behavior you're seeing, I may need to get a more complete test case from you (we can do this off-line, if needed).

~ Todd

Hi Todd,
I changed the .tdata to MSMCSRAM in the linker command file, and the linker successfully placed the .tdata section into where I wanted it to. But the same warning is generated about .tdata.