• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 54 subscribers
  • Views 651 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.

CCS: Compiler cl6x deletes output object file inside Docker container

David A. Luca
Intellectual 310 points
Other Parts Discussed in Thread: SYSBIOS

Tool/software: Code Composer Studio

Hello,

I'm having a weird issue, when running the command below in a Windows 10 command prompt the object file is generated ok, but when using Docker (built from Ubuntu 18.04 and installed Linux Code Generation tools v7.2.24) I can see the object file generated with similar file size and then deleted a couple of seconds later, is there some additional parameters I need to provide to keep the object file? 

cl6x -mv6748 --abi=eabi -O3 -ms3 -g --optimize_with_debug=on  --gcc --define=c6748 --diag_warning=225 --diag_wrap=off --display_error_number --gen_func_subsections=on --remove_hooks_when_inlining --printf_support=nofloat -D=WATCHDOG_STR=\"1\"  --preinclude="../PGM_sysbios/Include/platform.h" --include_path="/opt/ti/c6000_7.4.24/include" --include_path="../libStarterWare/StarterWare/include" --include_path="../libStarterWare/StarterWare/include/hw" --include_path="../libStarterWare/StarterWare/include/c674x" --include_path="../libStarterWare/StarterWare/include/c674x/c6748" --preproc_with_compile --preproc_dependency="Debug/FileManager.d" --obj_directory="Debug/" --asm_directory="Debug/"  "FileManager.cpp"

I tried echo "hello world" > test.obj in the Docker console and file is not being deleted which suggests cl6x compiler is the one responsible for deleting the object file but have no idea why. 

Best regards,

David.

  • 0
    TI__Guru**** 251820 points

    It might be a known problem related to compression.  Please try this experiment: Add the option --no_compress.  If that fixes the problem, then you need to upgrade to compiler version 8.3.2 or higher.

    This line edited in later ... The identifier of the known problem is CODEGEN-5457.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 310 points

    Hi George,

    That option seems to fix the issue, thank you. I'm reluctant to upgrade this legacy project to that compiler as I've tried it once (might have been 8.3.1 though) but firmware was unstable and crashing for some reason just after startup and couldn't debug the reason so had to downgrade to 7.2.24.

    These are the additional libraries that are currently used by the project:

    UIAPATH := /ti/uia_1_03_01_08
    XDCTOOLS := /ti/xdctools_3_25_06_96
    EDMA3 := /ti/edma3_lld_02_11_11_13
    BIOSPSP := /ti/biospsp_03_00_01_00
    DSPLIB := /ti/dsplib_c674x_3_1_1_1
    MATHLIB := /ti/mathlib_c674x_3_0_1_1
    SYSBIOS := /ti/bios_6_37_03_30
    XDAIS := /ti/xdais_7_21_01_07

    Best regards,

    David.

  • 0 in reply to David A. Luca
    TI__Guru**** 251820 points

    I understand.  Each of those components was developed with a version of the C6000 compiler that was widely available at the time the component was released.  It is usually wise to use the same compiler version.  

    Using --no_compress means your total memory usage has gone up.  If you are OK with that, then I guess that workaround solves your problem.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 310 points

    Unfortunately, it doesn't as I've just discovered it no longer fits in internal RAM. If this is a known issue, why is the compiler still available for download, since you cannot build anything?

  • 0 in reply to David A. Luca
    Intellectual 310 points

    So I tried compiling with 8.3.5 but when libc.a is being built, I get the following:

    <Linking>
    warning #10366-D: automatic library build: using library "C:\ti\ccs920\ccs\tools\compiler\ti-cgt-c6000_8.3.5\lib\rts6740_elf_mt_eh.lib" for the first time, so it must be built. This may take a few minutes.
    Creating library c:/users/d7615~1.luc/appdata/local/temp/ti_mkl~1/rts6740_elf_mt_eh.lib
    warning #10247-D: creating output section ".tdata" without a SECTIONS specification
    warning #10247-D: creating output section ".TI.tls_init" without a SECTIONS specification
    "tdeh_cpp_abi.cpp", line 219: warning #17003-D: relocation from function "__cxa_get_globals" to symbol "EH_GLOBAL_PTR" overflowed; the 30-bit relocated address 0x30a69677 is too large to encode in the 15-bit unsigned field (type = 'R_C6000_TPR_U15_W' (40), file = "C:\ti\ccs920\ccs\tools\compiler\ti-cgt-c6000_8.3.5\lib\rts6740_elf_mt_eh.lib<tdeh_cpp_abi.cpp.obj>", offset = 0x0000000c, section = ".text:__cxa_get_globals")
    "tdeh_cpp_abi.cpp", line 221: warning #17003-D: relocation from function "__cxa_get_globals" to symbol "EH_GLOBAL_PTR" overflowed; the 30-bit relocated address 0x30a69677 is too large to encode in the 15-bit unsigned field (type = 'R_C6000_TPR_U15_W' (40), file = "C:\ti\ccs920\ccs\tools\compiler\ti-cgt-c6000_8.3.5\lib\rts6740_elf_mt_eh.lib<tdeh_cpp_abi.cpp.obj>", offset = 0x00000034, section = ".text:__cxa_get_globals")
    "errno.c", line 88: warning #17003-D: relocation from function "__c6xabi_errno_addr" to symbol "__errno" overflowed; the 32-bit relocated address 0xc282d7a4 is too large to encode in the 15-bit unsigned field (type = 'R_C6000_TPR_U15_B' (38), file = "C:\ti\ccs920\ccs\tools\compiler\ti-cgt-c6000_8.3.5\lib\rts6740_elf_mt_eh.lib<errno.c.obj>", offset = 0x0000000c, section = ".text:__c6xabi_errno_addr")
    warning #10015-D: output file "PGM_sysbios.out" cannot be loaded and run on a target system

    The project files have been imported into CCSv9.2.0 but never seen before those kind of messages, any idea what those errors means?

    Best regards,

    David.

  • 0 in reply to David A. Luca
    TI__Guru**** 251820 points

    I presume you rely on the linker to automatically choose the RTS library.  If so, it appears the wrong one is chosen.  I don't understand why the library rts6740_elf_mt_eh.lib gets chosen.  Override it by explicitly using rts6740_elf.lib.  If your linker invocation refers to -llibc.a, then change it to -lrts6740_elf.lib.  If your linker invocation refers to no RTS library, then add -lrts6740_elf.lib to the end.

    Thanks and regards,

    -George