• Locked Locked
  • Replies 8 replies
  • Subscribers 55 subscribers
  • Views 1775 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

INTERNAL ERROR: c:\ti\ccsv6\tools\compiler\c6000_7.4.8\bin\lnk6x.exe failed to allocate memory

Shiran Ben Israel
Intellectual 530 points

Hi

I am trying to link a large project, sometimes (especially after restart) it managed to link. The link takes between 10 to 15 minutes. The out file was around 35Mb in debug

My computer is windows 7 64bit with 16GB ram.

I am using code composer 6.0.1.00040 

Compiler TI v7.4.8

In the linker options i tured on Eliminate sections not needed in the executable and Aggresively reduce size of DWARF information. When they were off the out file was around 100Mb and could not be loaded into the ROV.

In release it does manage to link, but the peak memory of the lnk6x,exe is 3,791,224k.

How can i link in debug

  • TI__Guru* 84285 points
    The compiler tools are build as 32-bit executables and thus suffer from the 4GB memory limit. You are likely running into that limit. We are aware of the issue and are trying to rectify it, but there's probably nothing that can be done for your test case other than the workaround you have found.

    The size of the target executable (out file) should not be relevant; only the size of the raw data should be relevant, and the executable file can be much larger than that due to debugging information and other overhead. What loader are you using? How do you know the file "could not be loaded" ? What error do you get?
  • in reply to Archaeologist
    Intellectual 530 points
    The reason that i had to aggresively reduce the size of the dwarf file is that without it i have the phenomenon described in the following thread
    http://e2e.ti.com/support/embedded/tirtos/f/355/t/382329. i cannot use RTOS.
    When i set these two flags to off the max memory that the linker got to was under 1GB and I do manage to link now
    However the out file becomes 265MB and that is a problem onto itself (besides not being able to use RTOS)
  • in reply to Shiran Ben Israel
    TI__Guru* 84285 points
    You could run strip6x on the executable out file to completely remove the debugging information for the purposes of loading.
  • in reply to Archaeologist
    TI__Guru* 95265 points
    Archaeologist,
    Customer contacted TI and with strip method, "But this way I can’t debug the code. So it is not a real solution." Do you see any other solutions?
    Regards, Eric
  • in reply to lding
    TI__Guru* 84285 points
    The user could selectively strip debugging from portions of the code, such as well-tested libraries that you aren't likely to need to debug. Other than reducing the size of the linker inputs, I don't see any way around the 4GB limit at this time. We are working to provide 64-bit tools, but there is no timeline for any sort of delivery.
  • in reply to Archaeologist
    Intellectual 530 points
    I tried running strip6x on a lib and I've gotten the error
    error: errors occurred while read the name of the lib
    I've tried this on several libs
    but on the out file it works

    so how am I supposed to strip debugging information from libs
  • in reply to Shiran Ben Israel
    TI__Guru**** 249680 points

    The utility strip6x cannot directly operate on a library.  You need to extract all the members of the library, perform strip on each one, then reconstruct the library.  Copy the library into an empty directory.  Then issue commands similar to ...

    % ar6x -x library_name.lib
% strip6x *.obj
% ar6x -r library_name.lib *.obj

    The command ar6x is the library archiver utility.  Both these utilities are documented in the C6000 assembly tools user's manual.

    Thanks and regards,

    -George

  • in reply to George Mock
    TI__Intellectual 2265 points

    All,

    Are we certain that this issue is being caused because the linker is 32-bits?

    I would be more suspicious of a memory usage/management error in the linker. Perhaps it is using an inefficient date structure that is exacerbated by the user's test case.

    I would recommend submitting a defect report against the linker for this issue.

    Shiran,

    If possible, can you provide a test case that reproduces this problem? Ideally, the test case should include object files, libraries, and the command (including any linker command files) used to invoke the linker.

    Thanks and Regards,

    Todd Snider