• Locked Locked
  • Replies 6 replies
  • Subscribers 54 subscribers
  • Views 793 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.

What does the "-oe" command line option do in cl470?

ScottAllen
Prodigy 30 points

I am trying to find some documentation on what this options does, it does not appear to be documented in the command line help and I cannot seem to find any info on it in the wikis. Internally I am working with a group to try and accelerate their build process using Electric Accelerator. When this option is not used, it's working fine, when this option is used, we have issues. Talking with support for this product (emake), they indicate the following:

Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4

Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 “/tmp” and eMake root (which is in the EFS) are treated as two different file systems by the OS. So a rename system call cannot be used to move files between the two locations. Usually most programs that uses the rename system call on Unix has a fall back behavior of copying the file to the new location and deleting the old one (like /bin/mv) because of such possibility. It seems that the command that you are calling does not do this, but just exits with an error."

 

The most obvious work around is to just remove the "-oe" option, but I need to understand what this impact would be.

Version info:

bash-3.00$ cl470 -version
TMS470 C/C++ Compiler                   v4.6.0
Build Number 1JHSK-JA47E4-UARAR-SAW-ZAZE_U_W_Q

Here is the actual command being executed in the build process:

Normal 0 false false false EN-US X-NONE X-NONE

/home/x0124169/build/dsptools/cgtarm-4.6.0/bin/cl470 -c  -qq -pdsw225 -ms -DOS_DSPBIOS  -DUSE_WA --endian=little -mv7M3 --abi=eabi -eo.oem3 -ea.sem3  -ms  -Dxdc_target_name__=M3 -Dxdc_target_types__=ti/targets/arm/elf/std.h -Dxdc_bld__profile_whole_program_debug -Dxdc_bld__vers_1_0_4_6_0 -oe --symdebug:dwarf -ms  -I. -I/home/x0124169/build/l27/27.x_DailyBuild_49/myfiles/ducati_samples_src -I/home/x0124169/build/dsptools/bios_6_21_02_19/packages -I/home/x0124169/build/dsptools/xdctools_3_16_02_32/packages -I../../.. -I/home/x0124169/build/dsptools/cgtarm-4.6.0/include/rts -I/home/x0124169/build/dsptools/cgtarm-4.6.0/include  -fs=./package/lib/lib/whole_program_debug/ti.sdo.utils -fr=./package/lib/lib/whole_program_debug/ti.sdo.utils -fc MultiProc.c

 

 

  • TI__Guru**** 249420 points

    The -oe option is part of a larger solution that has not been released yet.  You will see no impact from removing it.

    The fact that Electric Accelerator has a problem with the rename system call is interesting.  Never seen that before.  The compiler may use rename in connection with other options besides -oe.  I'm not sure.  I'll check with some of our experts on that.

    Thanks and regards,

    -George

     

  • in reply to George Mock
    TI__Prodigy 30 points

    Thanks for the info. Essentially what Accelerator is doing is reading from one file system (cache) and writing to another (locale since it has to write to it), which is why the rename system call does not work. There are some other work arounds, like using the -temp flag to place the files in a location that this will not occur (looking into this now).

    Let me know what you find on the renames...

     

    -scott

  • TI__Guru* 84285 points

    ScottAllen said:

    Internally I am working with a group to try and accelerate their build process using Electric Accelerator. [..] Talking with support for this product (emake), they indicate the following:

    “/tmp” and eMake root (which is in the EFS) are treated as two different file systems by the OS. So a rename system call cannot be used to move files between the two locations. Usually most programs that uses the rename system call on Unix has a fall back behavior of copying the file to the new location and deleting the old one (like /bin/mv) because of such possibility. It seems that the command that you are calling does not do this, but just exits with an error.

    What is the exact text of the error message?  Also, am I correct to assume that the user is using a Linux system?

  • in reply to Archaeologist
    TI__Prodigy 30 points

    It's an Electric Accelerator error, so not sure how much sense it will make but see below:

     

    [/home/x0124169/build/l27/27.x_DailyBuild_49/myfiles/ducati_samples_src/ipc/ti/sdo/utils/] ======== rm -f package/lib/lib/whole_program_debug/ti.sdo.utils/MultiProc.oem3

    #

    # clem3 MultiProc.c ...

    /home/x0124169/build/dsptools/cgtarm-4.6.0/bin/cl470 -c  -qq -pdsw225 -ms -DOS_DSPBIOS  -DUSE_WA --endian=little -mv7M3 --abi=eabi -eo.oem3 -ea.sem3  -ms  -Dxdc_target_name__=M3 -Dxdc_target_types__=ti/targets/arm/elf/std.h -Dxdc_bld__profile_whole_program_debug -Dxdc_bld__vers_1_0_4_6_0 -oe --symdebug:dwarf -ms  -I. -I/home/x0124169/build/l27/27.x_DailyBuild_49/myfiles/ducati_samples_src -I/home/x0124169/build/dsptools/bios_6_21_02_19/packages -I/home/x0124169/build/dsptools/xdctools_3_16_02_32/packages -I../../.. -I/home/x0124169/build/dsptools/cgtarm-4.6.0/include/rts -I/home/x0124169/build/dsptools/cgtarm-4.6.0/include  -fs=./package/lib/lib/whole_program_debug/ti.sdo.utils -fr=./package/lib/lib/whole_program_debug/ti.sdo.utils -fc MultiProc.c

    >>   error: unable to rename /var/tmp/agentemp-0/01142Q6t5zo to

    >> ./package/lib/lib/whole_program_debug/ti.sdo.utils/MultiProc.oem3: 

    >> Invalid cross-device link

     

    >> Compilation failure

    gmake[1]: *** [package/lib/lib/whole_program_debug/ti.sdo.utils/MultiProc.oem3] Error 1

    gmake: *** [/home/x0124169/build/l27/27.x_DailyBuild_49/myfiles/ducati_samples_src/ipc/ti/sdo/utils/,.libraries] Error 2

    make: *** [.utils] Error 2

    Finished build: 2355   Duration: 0:18 (m:s)   Cluster availability: 100%

  • in reply to ScottAllen
    TI__Guru* 84285 points

    This is a bug.  I've submitted defect report SDSCM00037170 to track this issue.

  • in reply to George Mock
    Prodigy 10 points

    George,

    I tried building without -oe flag but it failed when linking:

    /home/x0068941/build/dsptools/cgtarm-4.6.0/bin/lnk470 -w -q -u _c_int00 --zero_init=off  --opt='--endian=little -mv7M3 --abi=eabi -qq -pdsw225 -ms -DOS_DSPBIOS  -DUSE_WA  -ms  --symdebug:dwarf -ms -op2 -O3 -k -os --optimize_with_debug --inline_recursion_limit=20'  -q -o whole_program_debug/RCMSrvClnt_InterM3_Test_Core0.xem3 package/cfg/whole_program_debug/RCMSrvClnt_InterM3_Test_Core0_xem3.oem3 package/cfg/whole_program_debug/RCMSrvClnt_InterM3_Test_Core0/RCMSrvClnt_InterM3_Test_Core0.oem3  package/cfg/whole_program_debug/RCMSrvClnt_InterM3_Test_Core0_xem3.xdl --silicon_version=7M3 --strict_compatibility=on -c -m package/cfg//whole_program_debug/RCMSrvClnt_InterM3_Test_Core0.xem3.map  -l /home/x0068941/build/dsptools/cgtarm-4.6.0/lib/rtsv7M3_T_le_eabi.lib
    TP>> internal error: invalid foward reference

    >> Compilation failure
    error: failed to recompile

    >> Compilation failure
    gmake[1]: *** [whole_program_debug/RCMSrvClnt_InterM3_Test_Core0.xem3] Error 1
    gmake: *** [/home/x0068941/build/l27/27.4_RC0/myfiles/ducati_samples_src/ipc/ti/sdo/samples/rcm/,.executables] Error 2
    gmake: *** [.ducati_samples_all] Error 2

    Maybe removing -oe flag has unexpected effects on certain cases. Any ideas?

    -Luis