Asking help with (dwarf) exception hacking on mipsel

[Kertész Csaba <csaba dot kertesz at gmail dot com>]

Hi,

I have the following target system:

- Mips cpu (QED R7000, wikipedia says RM7000)
- no linux environment, binaries can be compiled for the system with
binutils+gcc+newlib toolchain
- there are no debugging tools, only writing with printf to a console
- only static binaries are supported with one thread
- the final binaries are in a special ELF format of the target system
by help of some binutils scripts.
- the sources of the base target system is not available. e.g. I do
not have the codes or binaries how it loads the ELF binaries in
run-time.
- the final binaries must be linked against some closed-source "system
libraries". they are compiled with gcc 3.3.6. There is no possibility
to recompile them, the source code (closed-source) is not available
now and never in the future.
- the original toolchain is binutils 2.15+gcc 3.3.6+newlib 1.15.
- dwarf based exceptions work with gcc 3.3.6.

My final target to upgrade the toolchain with gcc 4.4.x to have the
-mplt optimization available, but at least I must get a gcc 4.x
compiler to work. So far I have partial success with updating the
toolchain to binutils 2.17+gcc 4.1.2+newlib 1.15:

- I can compile binaries with the gcc 4.1.2 toolchain and run on the
target system.
- the issue of the old gcc 3.3.6 based system libraries: I link my
programs with libgcc and libstdc++ from gcc 3.3.6 as well, but I
renamed the symbols in the old system libraries, in the old libgcc and
in the old libstdc++. The old target system libraries uses the old
libgcc and the old stdc++ calls, the new codes compiled with gcc 4.1.2
uses the new stdc++ and libgcc calls.
- it seems everything works fine except one thing: the exceptions. :(

I tried sjlj exceptions and dwarf based exceptions with gcc 4.1.2. The
dwarf based exceptions drop an abort, the sjlj based exceptions crash.
I look into the problems with dwarf exceptions.

The reason of the failure of the dwarf based exceptions: The
_Unwind_Find_FDE (context->ra - 1, &context->bases); call in
gcc/unwind-dw2.c does not find the fde for the given PC
(context->ra-1). The context-ra is set by __builtin_return_address(0)
call when calling uw_init_context_1().

I iterated through the fdes when it tries to find in
binary_search_unencoded_fdes() and the relevant information is in
place. The fdes show the correct information what is in the binary
file: e.g symbol address 0x40081c (0x400000+code address).

I wrote a small program with a simple class:

class A {
void c() { c2(); }

void c2() {
...
throw an exception
...
catch the exception
...
}
};

When I execute a simple program using an instance of class A:

- The return address is returned by __builtin_return_address(0) when
searching the fde: 0x2344eca7
- The address of the class A instance where the exception is thrown: 0x2336b330
- The address A::c2(): 0x2336b2dc

It is obvious that the return address (pc) will not be found in the
fdes, because the address space in the fdes completely different,
around 0x400000-0x500000. On the other hand, it also different from
the address range of the class instance A.

Unfortunately, I can not compare the unwinding process between gcc 3.x
and 4.x on the target platform, because if I include printf()s with
format in the source code of gcc 3.x, it crashes. :(

What is wrong here? Can somebody give some help to solve this problem?

Thanks in advance,
  Csaba