cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
don.post
Visitor
Visitor
525 Views
Registered: ‎12-13-2019

MicroBlaze C++ Exception Handling - Standalone - 2020.2

Hi,

I am having trouble getting C++ exceptions to work as expected in 2020.2 with a standalone C++ application running on a MicroBlaze.  I searched for related answers and found some reports similar to what I am seeing in regards to the 2017 tool chain but nothing recent.  I created a  simple example starting with a blank standalone c++ application and then added the following code. I updated the linker script to increase the stack and heap sizes to 16K each. The program executes as expected until the "throw" is executed. The debugger shows the application ends up at _exit with the back trace showing abort was called. Any help would be greatly appreciated.

-Don

#include "xil_printf.h"
#include <iostream>

volatile uint32_t g_foo;
void testExceptions()
{
    static int counter = 0;
    counter++;
    xil_printf ("counter = %d\n\r", counter);
    if (counter == 10)
    {
         counter = 0;
         xil_printf ("throwing exception 20\n\r", );
         throw 20;
    }
}

int main (int argc, char** argv)
{
    xil_printf ("Hello world");
    std::cout << "From C++ stream hello" << std::endl;
    while(1)
    {
       try {
           testExceptions();
       }
       catch (...)
       {
           xil_printf ("Caught exception\n\r");
       }
    }

    // Delay for a bit
    for (int i = 0; i < 10000; i++)
    {
        uint32_t foo = g_foo;
    }
    return 0;
}

 image.png

7 Replies
zach_mahlet
Visitor
Visitor
362 Views
Registered: ‎05-15-2019

I am able to reproduce this behavior. Has anyone found a solution?

0 Kudos
don.post
Visitor
Visitor
342 Views
Registered: ‎12-13-2019

Hey Zach,

For a while there I thought I was the only one using C++ on the MicroBlaze :)...   Sadly there has no recognition from Xilinx that the issue exists nor any solution forth coming.  It is a big deal since some of the STL use them as a norm (std::stoi for example among many others)... Basically breaks the language's viability on the processor..  I am hoping the come out with a fix or at least let us know it is an issue and the are working on it...

-Don

0 Kudos
xilinxacct
Professor
Professor
327 Views
Registered: ‎10-23-2018

@don.post 

Do you have microblaze_exceptions enabled on your BSP?

Hope that Helps
If so, Please mark as solution accepted. Kudos also welcomed.

0 Kudos
don.post
Visitor
Visitor
319 Views
Registered: ‎12-13-2019

So not sure where they would be enable/disabled from.. Looking at the command line to gcc they are not explicitly being disabled. I have tried adding to the command line for gcc  "-fexceptions" and that made no difference. Same behavior.  Could you point me to where I should look to verify that exceptions are enabled in the BSP?

Thanks!

-Don 

0 Kudos
don.post
Visitor
Visitor
317 Views
Registered: ‎12-13-2019

And to be clear these are c++ exceptions we are talking about (throw / catch) and not hardware exceptions.  Thanks!

0 Kudos
xilinxacct
Professor
Professor
290 Views
Registered: ‎10-23-2018

@don.post 

If you are building you own BSP, it should be among those settings... (Not sure that will do it, but without that enabled, my understanding is that the microblaze instance does not even generate the branch instruction that would be used for exceptions.. a space saver).

Back around 2015, not including the iostream would result in the behavior you describe, but I see you have that included.... Others have also reported that upgrading the tool chain resolve that same issue, so if your not running something  current, that may be a path to success.

One other experiment, just for my curiosity... try a fully defined catch ... (e.g. catch (int e) )... rather than the wildcard (...), and see if that makes any difference.

 

Hope that Helps
If so, Please mark as solution accepted. Kudos also welcomed.

 

 

0 Kudos
don.post
Visitor
Visitor
194 Views
Registered: ‎12-13-2019

Thanks for the info.. So I am running 2020.2 which from what I can tell is the latest. Prior to posting I tried the global catch as shown, catching a user defined exception and then even tried throwing some of the std::exception ones and explicitly catching those. All test cases failed to be caught.   I am building my own BSP and I have looked for something obvious around this but all switches that I have found are related to enabling / disabling hardware exceptions and nothing to do with software ones.  Also bypassing the GUI and going straight at gcc, i've added the -fexceptions keyword which should force gcc to do the right thing and they still fail..

Any other suggestions would be greatly appreciated.

Thanks!

0 Kudos