OMAP-L138, ARM 9, SYS/BIOS, C++, exceptions handling

Damian Gowor

Other Parts Discussed in Thread: OMAP-L138

Hello,

I were testing some software on SYS/BIOS working on OMAPs ARM and I tried to turn on exceptions handling in compiler options. Unfortunately I am receiving following errors:

Does somebody know how to get rid of those errors?

over 13 years ago

0 ScottG over 13 years ago

TI__Mastermind 26780 points

Damian,

Can you please describe the specific settings you changed?

Thanks,
Scott

0 Damian Gowor over 13 years ago in reply to ScottG

Expert 1110 points

Well, starting from the beginning I have created a CCS C++ project for OMAP-L138 ARM (SYS/BIOS template). I have added a simple try-catch sentence and received error "#542 support for exception handling is disabled". So I changed the "Properties->TMS470 Compiler->Language Options->Enable C++ exception handling" option and I am receiving those errors that I have posted before. I have noticed just now that those errors appears after firs compiling. When I am clicking "Build Project" again those errors are gone. Now when I am trying to simulate the code using Texas Instruments Simulator after going to line "throw ..." system is calling first "loader_exit()" and then "abort()". I have created the same project for DSP core and there is no problem with exceptions.

0 ScottG over 13 years ago in reply to Damian Gowor

TI__Mastermind 26780 points

Damian,

OK, thanks.

I don’t have resolution, but wanted to let you know I’ve been looking at this and can recreate similar weird build messages. But they don’t go away if I build the project again.

Once C++ exceptions are enabled for the compiler the .ARM.extab and .ARM.exidx sections are generated. These sections are not placed in the default linker command files, and there are warning messages about this, and for my project, lots of symbol relocation overflow warnings too. I filed a bug report (Bug 369466) to get these two sections added to the default linker command files.

As a workaround, you can try placing these sections by adding script like this to the application .cfg file:

Program.sectMap[".ARM.exidx"] = "DDR";
Program.sectMap[".ARM.extab"] = "DDR";

When the program runs it still ends up aborting during the throw() – the C++ exception handling code calls terminate, which calls abort(), which ends up in loader_exit(). Without doing any of the catch() stuff.

I know you tried on the DSP, so I tried it on a Cortex M3 and see the catch code being properly called, and no termination. So it seems this runtime failure is specific to ARM9, or at least a subset of ARMs.

I need to work with the codegen team on this one, and will get back when I know more…

Scott

0 Damian Gowor over 13 years ago in reply to ScottG

Expert 1110 points

Scott,

Do you know maybe how long it will take to fix this bug? I am asking because I don't know should I start developing the software with error handling based not on exceptions or should I leave a place in the code for the exception handling.

0 ScottG over 13 years ago in reply to Damian Gowor

TI__Mastermind 26780 points

Damian,

Sorry, I don’t know yet. I’ve talked to the codegen team and posted on an internal forum and haven’t found anyone else having issues. My next step is to make a standalone test for ARM9 to rule out any SYS/BIOS-related interaction. I hope to get to that later today. I’m hoping it may be something simple (like a program build option for ARM9), but don’t know yet.

Scott

0 ScottG over 13 years ago in reply to ScottG

TI__Mastermind 26780 points

Damian,

FYI, I did some standalone testing (projects without SYS/BIOS) and still could not get try()/catch() to work on ARM9. The same standalone tests work on a Cortex M3. I submitted a project with a bug report for the compiler (SDSCM00043014). I’ll post back to the forum when I know more.

One other thing… have you looked at the Error handling services provided by xdc.runtime.Error?: http://rtsc.eclipse.org/docs-tip/Using_xdc.runtime_Errors I wonder if this might be a better alternative to C++ exceptions for you (anyways)?

Scott

0 Damian Gowor over 13 years ago in reply to ScottG

Expert 1110 points

Hello Scott,

Thank you for your help. I was considering this method but I didn't decide yet. I am waiting for information from you.

0 ScottG over 13 years ago in reply to Damian Gowor

TI__Mastermind 26780 points

Damian,

I have been talking with the codegen team about the exception issue but have no resolution yet. The standalone test case I submitted was failing because of not enough heap space (an override by the linker command file) and it now passes with enough heap. We now need to turn on some exception instrumentation and do a detailed step thru a failing case with SYS/BIOS to determine what is going wrong, but haven’t had the chance to do this yet. Is this a high priority item for you?

Thanks,
Scott

0 Damian Gowor over 13 years ago in reply to ScottG

Expert 1110 points

Scott,

At this moment I am handling exceptions in other way but in the future I would like to change it. Hope this bug will be fixed in next few weeks.

0 Damian Gowor over 13 years ago in reply to Damian Gowor

Expert 1110 points

Scott,

There is a possibility that we will be using Windows CE or some kind of Linux on OMAP-L138 ARM9 core.

Do you know are there any problems with C++ exceptions when using TMS470 compiler and developing

under those operating systems?

0 ScottG over 13 years ago in reply to Damian Gowor

TI__Mastermind 26780 points

Damian,

I expect the exception handling should work on either WinCE or Linux, since when I’d sent out queries there were no known issues on ARM9.

And also, because I was just putting together another test case and discovered what was going wrong. It wasn’t a codegen issue at all.

I’d originally told you to just add some Program.sectMap[] statements to your .cfg file for .ARM.exidx and .ARM.extab. It turns out that in the resultant linker command file these get specified as splittable sections (with the “>>” directive, versus “>”). If the linker does decide to spit these sections (for efficient placement) it is a big problem for the exception handling code.

The right way is to NOT add these in the .cfg file, but to simply add a supplementary linker command file to your CCS project. For example, add a linker.cmd file that contains this:

SECTIONS
{
.ARM.exidx: load > DDR
.ARM.extab: load > DDR
}

You can use a region other than DDR if you want.

I tested this change on a ARM9 simulator and on an OMAP-L138. Please let me know if this does not solve the issue for you.

Sorry for the confusion I caused with this!

Scott

0 Archaeologist over 13 years ago in reply to ScottG

TI__Guru* 84285 points

The correct thing to do here is to avoid using ">>" for .ARM.exidx, as Scott indicates. It is an error to attempt to split .ARM.exidx. However, the linker tries to be friendly in this case. It emits a warning and automatically changes ">>" to ">" for .ARM.exidx, but then fails to set up some special symbols that the exception handling code in the RTS library relies upon to find .ARM.exidx, which causes exception handling to fail completely. This is now defect report SDSCM00043014. In the meantime, if you see this warning, consider it an error:

"./lnk.cmd", line 46: warning: split placement (>>) ignored for ".ARM.exidx":
   cannot split EH Index table

Also, it should be safe to split .ARM.extab; it does not need to be contiguous.

0 Damian Gowor over 13 years ago in reply to Archaeologist

Expert 1110 points

Again this problem appeared in CCS v5.2 which I have installed. This time creating a linker command file with following content didn't help.

SECTIONS
{
.ARM.exidx: load > DDR
.ARM.extab: load > DDR
}

Is there any other way to resolve this problem in version 5.2 ?

Processors

Processors forum

OMAP-L138, ARM 9, SYS/BIOS, C++, exceptions handling