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

Part Number: TMS320C6678

Tool/software: TI C/C++ Compiler

Environment:

  1. CCS 7.1.0 build 16
  2. CGT 8.1.3
  3. SYSBIOS 6.50

Phenomenon:

  1. I have a SYSBIOS project which i can successfully create & run when I use the non-multithread version of RTS library (The linker parameter '--multithread' is not provided).
  2. When I link the multithreaded RTS library, I got the linking warning described below:

  • "errno.c", line 87: warning #17003-D: relocation from function "__c6xabi_errno_addr" to symbol "__errno" overflowed; the 24-bit relocated address 0x8376dc is too large to encode in the 15-bit unsigned field (type = 'R_C6000_TPR_U15_B' (38), file = "D:\devel\ti\ccs710\ccsv7\tools\compiler\ti-cgt-c6000_8.1.3\lib\rts6000_elf_mt.lib<errno.obj>", offset = 0x0000000c, section = ".text:__c6xabi_errno_addr")
  • warning #10015-D: output file "xxx.out" cannot be loaded and run on a target system.

I checked the errno.c and errno.h in the libsrc folder. I can see the __errno symbol is defined and declared using _DATA_ACCESS which is "__far".

Since the memmodel of the __errno is already FAR, it should be accessed from anywhere without using DP, but why I am getting the linking warning listed above?

8 Replies

  • 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

  • In reply to Todd Snider:

    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

  • In reply to canfoderiskii:

    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

  • In reply to 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.
  • In reply to canfoderiskii:

    canfoderiskii
    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


    TI C/C++ Compiler Forum Moderator
    Please click Verify Answer on the best reply to your question
    The CCS Youtube Channel
     has short how-to videos
    The 
    Compiler Wiki answers most common questions
    Track an issue with SDOWP. Enter your bug id in the Search box.

  • In reply to George Mock:

    The added extra linker .cmd file is simple:

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

  • In reply to canfoderiskii:

    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

  • In reply to Todd Snider:

    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.