Forums

Hi,

I am running into a few issues that arise when C++ Exceptions are enabled in my project.

1. In a large project, it is common that .c files are used alongside .cpp files. If exception handling is enabled in the project, however, the compiler will choke on every .c file with the error:
   
   Command-line error #593: exception handling option can be used only when compiling C++
   
   This forces me to have to manually go over each .c file and remove the checkbox that enables the --exceptions option in the project properties of CCS, a very tedious process. Wouldn't it be simpler if either (A) this were considered a warning by the compiler (and the option ignored), or (B) CCS would automatically prevent this option from affecting .c files?
   
   
2. When enabling exceptions in a project the following linker warning appears:
   
   warning #10247-D: creating output section ".c6xabi.exidx" without a SECTIONS specification
   warning #10247-D: creating output section ".c6xabi.extab" without a SECTIONS specification
   
   Now, the first thing I try (since RTSC based projects normally don't need a custom linker command file) is to add the following to my .cfg:
   
   Program.sectMap[".c6xabi.exidx"] = "DDR3";
   Program.sectMap[".c6xabi.extab"] = "DDR3";
   
   This results in an warning and the lines are ignored:
   
   "./configPkg/linker.cmd", line 218: warning #10094-D: split placement (>>)
      ignored for ".c6xabi.exidx":  cannot split EH Index table
   
   ..and so I am forced to create a custom linker command file to link correctly. My point here is that this process is a hassle and should be automatically taken care of by the system.
   
   
3. Once everything is in place, however, I have a problematic scenario. I am developing on a EVM6678, a multicore system. Typically I have all large shared, read-only sections in DDR and smaller, R/W sections in L2SRAM so that the different cores do not conflict. So, sections .text, .const, .cinit, .switch are all placed in DDR3 and the rest in L2SRAM. I have noticed that the .vecs section is modified at runtime (during the pre-main initialization) and so also place it in L2SRAM.
   
   There appears to be a tie between the two newly added sections and the .vecs section; they cannot be spaced too far apart. Now, if I place these sections in L2SRAM, a torrent of relocation overflow warnings are emitted by the linker - apparently they must be near .text. So, I place them in DDR3 and the link completes. However, if a large heap is defined in the .cfg it pushes the .text section further upwards in DDR memory (say, 0x88000000 instead of 0x80000000) and this causes the following linker message:
   
   warning #17003-D: relocation to symbol "__TI_exidx_linkto_scn_start_2"
      overflowed; the 32-bit relocated address 0xbc3f68c0 is too large to encode
      in the 31-bit signed PC-Relative field (type = 'R_C6000_PREL31' (25), file =
      "(unknown file)", offset = 0x00000000, section =
      ".c6xabi.exidx.vecs:app_pe66.oe66")
   warning #10015-D: output file "mydemo.out" cannot be loaded and run on a target
      system
   
   Now, this could be solved by defining the heap at runtime rather than at config time, or forcing the linker to insert .text lower than the heap (these are two ways to keep the .text in low DDR memory), but I am looking for a more elegant solution. For example, it would be nice if I could leave most of .c6xabi.exidx in DDR but move just the part that needs to be near .vecs into L2SRAM using a linker command. Is this possible?
   
   I am attaching a sample project that demonstrates this under CCS 5.1 and CGT 7.3.2.
   
   2514.mydemo.zip

Thanks,

-itay