This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Part Number: TMS320C6678
Tool/software: TI C/C++ Compiler
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?
Happy coding, Keep learning...
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.
Texas Instruments Incorporated
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
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:
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.
canfoderiskiiEven 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,
TI C/C++ Compiler Forum ModeratorPlease click This Resolved My Issue on the best reply to your questionThe CCS Youtube Channel has short how-to videosThe Compiler Wiki answers most common questionsTrack 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:
.TI.tls > L2SRAM
.TI.tls_init > L2SRAM
.tdata > L2SRAM
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).
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.