Code Composer v5.5 - Exception Handling Questions

1. Operations which are expected to throw an exception simply won't; they will usually stop and return.  operator new will return a NULL value
2. We recommend you use EABI.  In this case, there is almost no execution overhead unless an exception is thrown.  See http://processors.wiki.ti.com/index.php/Overview_of_C%2B%2B_Support_in_TI_Compilers
3. How do you know it is not running correctly?  Exactly what symptom do you see?  Where do you first notice a problem?
4. The very latest compilers support a C99 mode.  See http://processors.wiki.ti.com/index.php/C99_in_TI_Compilers  Why did it take so long?  Lack of demand, and by that I mean there weren't enough big designs that absolutely depended on C99 support.

CCS Champs,

Thanks for your help with this! GE is still having some dificulty with items 1 and 3.

1. What happens when there is an error that would normally cause an exception such an in a dynamic memory allocation or STL code?

[GE] The new operator is an easy case since it has a return value.  What about verctor::push_back?  It has no return value. It states, “If a reallocation happens, the storage is allocated using the container's allocator, which may throw exceptions on failure (for the default allocator, bad_alloc is thrown if the allocation request does not succeed).” In this case, it we get no response and the code just returns, we are left in a bad state with no knowledge of the failure.  This is what I was worried about. It seems like if we are using these type of features we will need to make sure exceptions are enabled. Comments? 

3. We tried to enable C++ exception handling in the language options and the code compiles, but it does not seem to run correctly.  We can’t step through code and it does not seem to be running.  Are there other steps that we should be aware or any known issues?

[GE] The code compiles, but we can’t step through code or set break points and we no longer see printfs that we put in the code.  That is why we think it is not running.  In the link that you sent me it says, “Using exceptions also requires you to link with a special version of the compiler runtime support library. For example, when building for a C6400 device, use rts6400_eh.lib instead of rts6400.lib. Note eh stands for exception handling.”  I do not think we are using any libraries.   Here is our project information:

How do we know if we are sing the correct one?

C6000 Compiler Command

-mv6740 --abi=coffabi -g --include_path="C:/ti/ccsv5/tools/compiler/c6000_7.4.4/include" --include_path="D:/Bently/" --include_path="D:/Bently/FwShared/Interfaces/HardwareStatus/PreRelease/" --include_path="D:/Bently/FwShared/Interfaces/Timer/PreRelease/" --include_path="D:/Bently/FwShared/Libraries/Alarms/PreRelease/" --include_path="D:/Bently/FwShared/Libraries/AssertManager/PreRelease/" --include_path="D:/Bently/FwShared/Libraries/FwTypes/PreRelease/" --include_path="D:/Bently/FwShared/Libraries/SignalProcessing/PreRelease/" --include_path="D:/Bently/FwShared/Libraries/TimeLogger/PreRelease/" --include_path="D:/Bently/FwShared/Libraries/UnitTestFramework/PreRelease/" --include_path="C:/ti/xdctools_3_25_03_72/packages" --rtti --define=DISABLE_CSTDINT=1 --display_error_number --diag_warning=225 --diag_wrap=off

C6000 Linker Command:

-mv6740 --abi=coffabi -g --rtti --define=DISABLE_CSTDINT=1 --display_error_number --diag_warning=225 --diag_wrap=off -z -m"FwSharedUnitTests.map" -i"C:/ti/ccsv5/tools/compiler/c6000_7.4.4/lib" -i"C:/ti/ccsv5/tools/compiler/c6000_7.4.4/include" --reread_libs --warn_sections --display_error_number --diag_wrap=off --xml_link_info="FwSharedUnitTests_linkInfo.xml" --rom_model

Michael Questo said:

In the link that you sent me it says, “Using exceptions also requires you to link with a special version of the compiler runtime support library. For example, when building for a C6400 device, use rts6400_eh.lib instead of rts6400.lib. Note eh stands for exception handling.”  I do not think we are using any libraries.   Here is our project information:

How do we know if we are sing the correct one?

The linker will automatically try to link a compatible RTS library.  If the linker weren't able to find such a library, you would get many link-time errors regarding undefined symbols required for compiler support, such as the exception-handling mechanism.

Generate a linker map file with the linker option --map_file; it should be very clear from the map file which library the linker chose for you.

Michael Questo said:

1. What happens when there is an error that would normally cause an exception such an in a dynamic memory allocation or STL code?

[GE] The new operator is an easy case since it has a return value.  What about verctor::push_back?  It has no return value. It states, “If a reallocation happens, the storage is allocated using the container's allocator, which may throw exceptions on failure (for the default allocator, bad_alloc is thrown if the allocation request does not succeed).” In this case, it we get no response and the code just returns, we are left in a bad state with no knowledge of the failure.  This is what I was worried about. It seems like if we are using these type of features we will need to make sure exceptions are enabled. Comments? 

The C++ standard does not specify what happens in an environment without exceptions.  That is, the behavior of vector::push_back upon failure of "operator new" is not specified.  In other words, there's no reliable way to determine whether push_back failed without enabling exceptions.  See

http://stackoverflow.com/questions/9553225/working-with-a-c-compiler-that-doesnt-support-exceptions

From looking at the implementation in the RTS source code (available in your installed compiler release), it would appear that the library will call operator new (placement) with a NULL pointer, and will delete the original contents unconditionally.  You could possibly survive by redefining operator new (placement) with a function that checks for NULL and aborts the program, but I doubt you could recover from such an error - that's a job for exception handling.  If you disable exceptions, you should avoid making any library call which normally might throw an exception on memory allocation failure if you are not confident there is plenty of memory available.

If you have room to spare, how would the compiler or linker know there was a problem to warn about?  We don't really have the faintest idea of what's wrong with the test case, so it's impossible to say whether the compiler should have caught it.

They think they've found the problem.  Even though the map states that there is free IRAM, 128k was allocated for L2 cache.  So out of our 256k, we were trying to use 177k (2C77B was reported used for IRAM with Exception Handling enabled).  I also found a warning was being reported during the build:

warning: ti.sysbios.family.c64p.Cache: "C:/ti/bios_6_35_04_50/packages/ti/sysbios/family/c64p/Cache.xs", line 497: ti.sysbios.family.c64p.Cache : Cache settings were changed in user configuration. User configuration options will override platform settings. Check your memory map to make sure that Cache does not conflict with your L1/L2 memory placement. To avoid conflicts between L1/L2 memory and cache, we recommended specifying cache sizes along with memory sizes in a platform package.

I assume if we specified the cache as stated in the warning, we would have received a linker warning instead of the program actually running and resulting in the erratic behavior we’ve noticed. I’m not familiar with CCS or SYS/BIOS (we just copied this project from another program here), any ideas on how to fix this warning? 

Hi Michael,

I don't know the reason for that warning off the top of my head, but let me see if I can find the root cause.  In the meantime, would it be possible for you to post the project config file (.cfg) here?

Thanks,

-- Emmanuel

Thanks for taking a look at this Emmanuel.

Here is the .cfg file.

6428.fullBios.cfg

In that version they've already moved the .far and .cinit sections to DDR (instead of IRAM).  This fixed our instability, but we still have the warning.

Thank you for your help with this question and your prompt responses.  I realize it was a very long running thread.  I will verify the thread as soon as i get a confirmed response from the customer.  Great support guys! 

Hey guys.

Were having some trouble creating the new platform...

1. Is there a guide somewhere to creating a new platform that I could follow?
   1. While I assume we’ll be able to get rid of this warning, I’m curious if there should have been an error generated when we violated the amount of memory available.  Considering we specified the size of IRAM to be 256k, then assigned 128k to L2, shouldn’t we get some error when the compile assigns a value greater than 128k to the remainder of IRAM?
2. I’m also trying to create an EABI project as we mentioned earlier.  I created a new CCS project using the Minimal SYS/BIOS template and set the Output format to EABI.  After important our C++ code (no external libraries needed), I’m getting the following linker error:

undefined first referenced                                                        

  symbol       in file                                                              

 --------- ----------------                                                        

 main      C:\ti\ccsv5\tools\compiler\c6000_7.4.4\lib\rts6740_elf.lib<args_main.obj>

   Is there a library I need to include for EABI?

Hey,

Quick update.

#1 GE has figured this one out.

For #2, it appears that main.cpp must be located in the “root” of the project directory with EABI?  The error went away when I moved it from the /src directory I had added.  Is that expected?