Hello all, I have determined that the default exception handlers for uncaught exceptions, memory allocation failures, etc. that come pre-compiled in the libstdc++ library perform a write to 'stderr' when executed. This causes the linker to include 'open/read/write/close' along with a whole bunch of string functions and greatly adds to the code and data size. While there are run-time functions for redirecting these default handlers to point to user code, the pre-compiled routines still get linked in. Is there a way to extract the default handlers from the libstdc++ library and replace them with my own versions so that no stream IO is performed? If anyone knows how to do this or knows where to get docs discussing this in more detail, I'd appreciate it. Cheers! Daniel Quinz, P. Eng. Acacetus Inc.
Dan Quinz wrote: > Is there a way to extract the default handlers from the libstdc++ > library and replace them with my own versions so that no stream IO is > performed? I've been wondering this as well! I'd love to get rid of the exception handling stuff to free up some flash and ram space. I've been looking into it but haven't made any progress. Let me know if you find anything interest please. Thanks
Actually, now that I think about it, I want to removed exception
handling entirely. For instance:
0x124
c:/winarm/bin/../lib/gcc/arm-elf/4.1.2/../../../../arm-elf/lib/thumb/int
erwork\libstdc++.a(eh_alloc.o)
0x000196bc __cxa_free_exception
0x000196f8 __cxa_allocate_exception
.text 0x000197e0 0x34
c:/winarm/bin/../lib/gcc/arm-elf/4.1.2/../../../../arm-elf/lib/thumb/int
erwork\libstdc++.a(eh_call.o)
0x000197e0 __cxa_call_terminate
.text 0x00019814 0x154
c:/winarm/bin/../lib/gcc/arm-elf/4.1.2/../../../../arm-elf/lib/thumb/int
erwork\libstdc++.a(eh_catch.o)
0x0001981c std::uncaught_exception()
0x00019814 __cxa_get_exception_ptr
0x00019830 __cxa_end_catch
0x00019898 __cxa_begin_catch
.text 0x00019968 0x7c
c:/winarm/bin/../lib/gcc/arm-elf/4.1.2/../../../../arm-elf/lib/thumb/int
erwork\libstdc++.a(eh_exception.o)
0x00019994 std::exception::~exception()
0x00019968 std::exception::what() const
0x000199d0
std::bad_exception::~bad_exception()
0x000199bc
std::bad_exception::~bad_exception()
0x000199a0
std::bad_exception::~bad_exception()
0x00019988 std::exception::~exception()
0x00019974 std::exception::~exception()
.text 0x000199e4 0x10
c:/winarm/bin/../lib/gcc/arm-elf/4.1.2/../../../../arm-elf/lib/thumb/int
erwork\libstdc++.a(eh_globals.o)
0x000199e4 __cxa_get_globals_fast
0x000199ec __cxa_get_globals
.text 0x000199f4 0x14
c:/winarm/bin/../lib/gcc/arm-elf/4.1.2/../../../../arm-elf/lib/thumb/int
erwork\libstdc++.a(eh_type.o)
0x000199f4 __cxa_current_exception_type
I do not need or want those. However, I have added -fno-exceptions and
-fno-enforce-eh-specs to my makefile, and they still get included. Any
one have any ideas?
Hi Jim,
I have found a compile and link setup that seems to eliminate all teh
exception handling code (as long as you don't use exceptions).
Here it is:
Compile:
arm-elf-g++ -c -ffunction-sections -fdata-sections -fno-builtin
-gdwarf-2 -O3 -Wall -Wcast-align -Wcast-qual -Wimplicit -Wpointer-arith
-Wswitch -Wredundant-decls -Wreturn-type -Wunused -mno-sched-prolog
-fno-rtti -fno-exceptions -mcpu=arm7tdmi -DXTAL_OSC=20000000
-DOS_USE_HOOK_CONTEXT=0 -DDBG_IMAGE=0 -DEXTERN_C_ENTER="extern \"C\" {"
-DEXTERN_C_LEAVE="} ;" -I. -Iinc.device -Iinc.hw_lpc -Iinc.task
-Iinc.void -Ilib.can -Ilib.clk_info -Ilib.dbg -Ilib.hw_can -Ilib.hw_uart
-Ilib.iap -Ilib.info -Ilib.os -Ilib.os_lpc -Ilib.reset -Ilib.sio
-Ilib.sio_uart -Ilib.sys -Ilib.task_main -Ilib.ui -Ilib.vic -Ilib.wdog
-Ibin.main -Wa,-adhlns=lib.wdog/lib.lpc/wdog_reset.lst -MD -MP
wdog_reset.cpp -o lib.lpc/wdog_reset.o
Link:
arm-elf-gcc -gdwarf-2 -O3 -MD -MP -nostartfiles -Wl,--gc-sections
-mcpu=arm7tdmi -I. -Wa,-adhlns=main.lst crt0.o main.o --output main.elf
-Wl,-Map=main.map,--cref -lstdc++ -lgcc -lc -lm -lnewlib-lpc
-Tlpc2129.ld
arm-elf-objcopy -O ihex main.elf main.hex
arm-elf-objdump -h -S -C main.elf > main.lss
arm-elf-nm -n main.elf > main.sym
When I compile and link with these options, the executable for my little
test program is only 2k with minimal RAM. This is small when compared
to the original 40k+ FLASH and 2k+ RAM when exception handling is used.
Hope this helps you.
Cheers!
Dan
Jim Kaz wrote:
> Actually, now that I think about it, I want to removed exception
> handling entirely. For instance:
>
> 0x124
> c:/winarm/bin/../lib/gcc/arm-elf/4.1.2/../../../../arm-elf/lib/thumb/int
erwork\libstdc++.a(eh_alloc.o)
> 0x000196bc __cxa_free_exception
> 0x000196f8 __cxa_allocate_exception
> .text 0x000197e0 0x34
> c:/winarm/bin/../lib/gcc/arm-elf/4.1.2/../../../../arm-elf/lib/thumb/int
erwork\libstdc++.a(eh_call.o)
> 0x000197e0 __cxa_call_terminate
> .text 0x00019814 0x154
> c:/winarm/bin/../lib/gcc/arm-elf/4.1.2/../../../../arm-elf/lib/thumb/int
erwork\libstdc++.a(eh_catch.o)
> 0x0001981c std::uncaught_exception()
> 0x00019814 __cxa_get_exception_ptr
> 0x00019830 __cxa_end_catch
> 0x00019898 __cxa_begin_catch
> .text 0x00019968 0x7c
> c:/winarm/bin/../lib/gcc/arm-elf/4.1.2/../../../../arm-elf/lib/thumb/int
erwork\libstdc++.a(eh_exception.o)
> 0x00019994 std::exception::~exception()
> 0x00019968 std::exception::what() const
> 0x000199d0
> std::bad_exception::~bad_exception()
> 0x000199bc
> std::bad_exception::~bad_exception()
> 0x000199a0
> std::bad_exception::~bad_exception()
> 0x00019988 std::exception::~exception()
> 0x00019974 std::exception::~exception()
> .text 0x000199e4 0x10
> c:/winarm/bin/../lib/gcc/arm-elf/4.1.2/../../../../arm-elf/lib/thumb/int
erwork\libstdc++.a(eh_globals.o)
> 0x000199e4 __cxa_get_globals_fast
> 0x000199ec __cxa_get_globals
> .text 0x000199f4 0x14
> c:/winarm/bin/../lib/gcc/arm-elf/4.1.2/../../../../arm-elf/lib/thumb/int
erwork\libstdc++.a(eh_type.o)
> 0x000199f4 __cxa_current_exception_type
>
>
> I do not need or want those. However, I have added -fno-exceptions and
> -fno-enforce-eh-specs to my makefile, and they still get included. Any
> one have any ideas?
Dan Quinz wrote: > When I compile and link with these options, the executable for my little > test program is only 2k with minimal RAM. This is small when compared > to the original 40k+ FLASH and 2k+ RAM when exception handling is used. > > Hope this helps you. > > Cheers! > > Dan Sweet! Thanks Dan! I'll try this out as soon as I get the chance, but sadly optimizing code space is the least of my concerns right now. So much to do and so little time... I hate deadlines :(
Jim, I also discovered that when you create an class object instance as
a static variable within a function, the compiler will use dynamic
memory allocation. This in turn can throw an exception, which links in
all the additional stuff. If you declare the object as global or
file-static, it does not. Keep that in mind!
Ex:
Object obj ; // Global, ok.
static Object obj; // File static, ok.
void some_func (void)
{
static Object obj; // Will call dynamic allocation -> bigger
code!!
Object obj; // No dynamic call, so ok.
}
Perhaps this is what is causing the stuff to be linked in your case?
Cheers!
Dan
Jim Kaz wrote:
> Dan Quinz wrote:
>> When I compile and link with these options, the executable for my little
>> test program is only 2k with minimal RAM. This is small when compared
>> to the original 40k+ FLASH and 2k+ RAM when exception handling is used.
>>
>> Hope this helps you.
>>
>> Cheers!
>>
>> Dan
>
> Sweet! Thanks Dan! I'll try this out as soon as I get the chance, but
> sadly optimizing code space is the least of my concerns right now. So
> much to do and so little time... I hate deadlines :(
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.