Hi,
Unfortunately, the target platform does not have Linux-like
environment, so there are no any debugging tools like gdb. The only
possibility to use printf()s (or introduce an artificial crash and get
the registers saved in a file after the system shut down). :(
Csaba
2010/10/6 David Daney <ddaney@xxxxxxxxxxxxxxxxxx>:
> On 10/06/2010 11:13 AM, Kertész Csaba wrote:
>>
>> 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?
>>
>
> I don't have any idea what the problem is, but I do think that debugging the
> DWARF exception handling code with only printf() may be impossible.
>
> I would suggest tracing through with GDB to see where it goes wrong.
> Rebuilding libgcc with '-O0 -g3' would make this easier.
>
> David Daney
>
