UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor andyfeds
Visitor
5,074 Views
Registered: ‎02-03-2011

Microblaze C++ exception handling failure with gcc 4.1.2/linux 2.6.33

Jump to solution

Hi,

 

I'm getting segfaults when running this trivial C++ exception handling test on microblaze:

#include <stdio.h>
using namespace std;

int main (int argc, char** argv)
{
  try
  {
    throw 42;
  }
  catch (...)
  {
    fprintf(stdout, "Hello world!\n");
  }
  return 0;
}

I'm using the mb_gnu_tools_bin.tar.bz toolchain (containg gcc 4.1.2/glibc 2.3.6 etc.) plus the linux-2.6-xlnx.tar.bz2 kernel (2.6.33), both from git.xilinx.com.

 

This only happens if I use shared libraries and PIC e.g.

mb-linux-gcc extest.cpp - o extest -fPIC -lstdc++ -I/...

Removing the -fPIC fixes the problem in this example - but I need it to compile many shared libraries (e.g. boost) and I want to be sure the exception handling is working correctly.

 

I also noticed the GOT register (r20) is corrupt when the catch { } block runs. If I force it back to it's original value then the printf works OK and the program does not segfault...

int main (int argc, char** argv)
{
  register unsigned long r20 __asm__("r20");
  unsigned long keep_r20 = r20;

  try
  {
    throw 42;
  }
  catch (...)
  {
    r20 = keep_r20;
    fprintf(stdout, "Hello world!\n");
  }
  return 0;
}

Please can anyone explain this crazy behaviour?

 

Andy

 

0 Kudos
1 Solution

Accepted Solutions
Visitor andyfeds
Visitor
6,233 Views
Registered: ‎02-03-2011

Re: Microblaze C++ exception handling failure with gcc 4.1.2/linux 2.6.33

Jump to solution

In case anyone was curious - this problem was solved by a toolchain update.

 

The new toolchain generates additional code to restore r20 (GOT) before the catch {} block - which is consistent with the original problem.

 

Andy

0 Kudos
3 Replies
Highlighted
Explorer
Explorer
5,011 Views
Registered: ‎08-14-2007

Re: Microblaze C++ exception handling failure with gcc 4.1.2/linux 2.6.33

Jump to solution
Without digging into either binary, which version of glibc is in the kernel image you are using? Also, if the kernel is a "binary" image, are you sure that the same version of the tools were used to build the kernel and the libs? Are you sure the correct shared library is in your filesystem? Previously for the PPC405, the eabi toolchain from Xilinx did not match a toolchain built using crosstools.
0 Kudos
Visitor andyfeds
Visitor
4,989 Views
Registered: ‎02-03-2011

Re: Microblaze C++ exception handling failure with gcc 4.1.2/linux 2.6.33

Jump to solution

Thank you for the questions!

 

I'm compiling the kernel myself with the same toolchain. It contains copies of the toolchain library files inside an initramfs image. So the application is running with the same libaries that it was compiled against.

 

(There was one slight difference - I'm using miniroot to build this initramfs image & it runs sstrip on the libs to save some space. However the problem remains even if I disable sstrip.)

 

My precompiled toolchain provides glibc 2.3.6 & libstdc++ 6.0.8. Sadly I cannot yet recompile this toolchain to add debug or try later versions.

 

I don't know exactly which Linux headers the toolchain itself was compiled against, but I doubt this is a kernel problem. It currently looks more like a C++ exception unwinding problem in user space.

 

Andy

 

0 Kudos
Visitor andyfeds
Visitor
6,234 Views
Registered: ‎02-03-2011

Re: Microblaze C++ exception handling failure with gcc 4.1.2/linux 2.6.33

Jump to solution

In case anyone was curious - this problem was solved by a toolchain update.

 

The new toolchain generates additional code to restore r20 (GOT) before the catch {} block - which is consistent with the original problem.

 

Andy

0 Kudos