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 4.2.3, CGTools 7.2.0 C++ try{}/catch{} behavior

 

I have a relatively large application(100MB w/symbols).  When I build with -abi=coffabi/rts6400_eh.lib, the behavior

of all my try{}/catch{} blocks is correct.  When I build with -abi=eabi/rts6400_elf_eh.lib, which is my preference, certain

try{}/catch{} blocks misbehave my returning to the wrong point in the code(not even a catch statement)

after a throw.  This is running on a c64xx cpu cycle accurate simulator.

 

I have traced this through a debug build of rts6400_elf_eh.lib and the return point coming out of

rtssrc/tdeh_uwentry_c6000.asm is incorrect.  Is this a known issue, do I have something misconfigured,

and/or is there a version of cgtools that doesn't exhibit this behavior?

 

Regards, Jason Kalin

  • No, it's not a known issue.  I doubt you have anything misconfigured.  Try using the --no_compress compiler option to see if it works around the problem.  I don't know of anything related which would have been fixed in the most recent version, but it would be worth trying to see if it fixes the problem.  The EABI exception handling code is pretty hairy, I don't recommend trying to debug it, but if you want to try, look at tdeh_common.h in rtssrc.zip, set the macro DEBUG_TDEH, and recompile the RTS; the output should tell you where things go wrong.  We will probably need a test case to diagnose this further.

  •  

    I rebuilt with --no_compress but it did not make any difference.

    I will see how feasibile it is for me to put together a large example at this point.

    A couple of additional pieces of information:

     

    1) Under -abi=coffabi I get no warnings, but under -abi=eabi I get some assembler warnings of the following type on some files?:

    "C:\temp\0346810" WARNING! at line 178909: [W0001] Value truncated to 16-bit width

    .half $EXTAB_SCOPE($C$L3381) - $EXTAB_SCOPE(_Z12AbsImageTestIeEvRK9MAbsImageIT_E) + 2;  scope offset

    (I tried a mem_model:data/const=far as I don't understand the warning but that didn't stop the warnings or have an effect)

    2) The code is heavily templated with significant inlining as well and these occurrences seem to be centered in this code.

    3) The return point isn't necessarily random, it usually seems to return to end of the method inside of which the try{}/catch{}

    is failing - does this imply the stack unwind is going too far?

    4) Creating a small example with somewhat similar properties does not exhibit the problem.

     

    I will throw in one other question here - When I set the silicon_version=6400+, the eventual goal,

    I am unable to compile a couple of the template instantiation files as the compiler hits the 2GB

    windows process limit and runs out of memory and is killed.  Other than more horsepower, and

    splitting the instantiations into smaller compilation units(which I've done in some cases) is there

    a way to prevent this much memory usage for template generation/instantiation?  I have no issues

    like this when building for an x86 linux/windows platform.  Also, compilation takes about 3 times

    longer with silicon_version=6400+ for all files - is this expected?

     

    Regards, Jason Kalin

     

     

     

  • Jason Kalin said:

    1) Under -abi=coffabi I get no warnings, but under -abi=eabi I get some assembler warnings of the following type on some files?:

    "C:\temp\0346810" WARNING! at line 178909: [W0001] Value truncated to 16-bit width

    .half $EXTAB_SCOPE($C$L3381) - $EXTAB_SCOPE(_Z12AbsImageTestIeEvRK9MAbsImageIT_E) + 2;  scope offset

    That is a pretty severe bug.  This is probably the source of your problem.  The compiler attempts to optimize the size of EXTAB entries (one part of EABI exception handling metadata) based on whether it thinks the result will fit in 16 bits; in this case, the compiler thinks "yes", but the real answer is "no."  We will need a test case to diagnose this.  We will need enough source files (possibly preprocessed) to generate that warning.

    Jason Kalin said:

    When I set the silicon_version=6400+, the eventual goal, I am unable to compile a couple of the template instantiation files as the compiler hits the 2GB windows process limit and runs out of memory and is killed.  Other than more horsepower, and splitting the instantiations into smaller compilation units(which I've done in some cases) is there a way to prevent this much memory usage for template generation/instantiation? 

    There's no way to directly control it.  We have made an effort to reduce the maximum amount of memory used by the compiler, but some programs are just too big.  What you really need is a 64-bit version of the compiler, which TI does not have at this time.  I've submitted enhancement request SDSCM00040287 to track this issue.

    Jason Kalin said:

    Also, compilation takes about 3 times longer with silicon_version=6400+ for all files - is this expected?

    Sorry, I don't know.  I do know that for some test cases, compiling EABI for targets which have compressed code (such as C64x+) can take longer, but I'm not sure about the expected values.  Does it run faster when you use --no_compress?  How does the run time compare to --silicon_version=6400?