is how I find the “heavy hitters”. I know that __cxa_* is run-time support. For _dtoa_r, I was suspicious because the disassembled code featured many calls to builtin_(insert arithmetic function name here)* things, while i’m not doing any FPU things internally. I tried replacing all the *printf with *iprintf and *scanf with *scanf and then I realised that at some point, both function actually called the same internal function that contains the full logic for floating points as well (maybe it’s due to vsniprintf and that iprintf would be just fine).

I then got clued from the library content that “dtoa” is likely “double-to-ascii”, and decided to replace it with a “runtime error report” function. So far, it didn’t affected the functionality of the code.

The story for __cxa_demangle was more complicated. Initially, the function i was suspicious about was d_print_comp. Again, i tried disassembling and tracing back “who calls that”, but it turned out that noone actually called it (that is, it is a virtual function of some sort, called only through a pointer and the content is statically defined). then i scanned lib*.a for a hit on d_print_comp (DS/dka-r21/arm-eabi/lib/libsupc++.a, if you ask), who revealed the symbol was present from cp-demangle.o, where d_print_comp is a “static” (internal) symbol, and __cxa_demangle is the only “external” symbol. I further googled for information on __cxa_demangle, and found http://idlebox.net/2008/0901-stacktrace-demangled/cxa_demangle.htt, where I found the error codes, full function prototype, etc. I gave “status=-2″ a try with a dummy exception, and all of sudden, it reports 16iScriptException to be caught, while the code shrunk by ~100K. Bingo.

Similarly, i identified __cxa_terminate() which i succesfully replaced using std::set_terminate(my_terminator) who is responsible from handling uncaught exceptions. I don’t feel like just abort()ing a DS program, so now when I got that, I fall back to a “press A to return to moonshell, B to download software upgrade” menu.

Yet, I’m not hot about killing __cxa_guard_acquire() and __cxa_guard_release(). They are required to ensure you got a lock (guard) on the static initialisation. They’re defined in guard.o, and from what I see of nm output on libsupc++.a, they rely on throw, unwind, class-type-info, etc., but not __cxa_demangle directly. Even if they would, i did not _remove_ __cxa_demangle here, just replaced it with a “oh, sorry. I cannot demangle that for you. How about showing it raw to the user ?”

There are also two others that I found out about recently: __cxa_guard_acquire() and __cxa_guard_release(). They were introduced when I tried to create a local const
array using data from a global constant instance that used templates. I’m assuming these call __cxa_demangle() at some point, but I can’t be sure.

 /** these are heavy guys from the lib i want to strip out. **/
 extern "C" char* _dtoa_r(_reent*, double, int, int, int*, int*, char**) {
   die(__FILE__, __LINE__);
 }

 extern "C" char* __cxa_demangle(const char* mangled_name,
 		       char* output_buffer, size_t* length,
 		       int* status) {
   if (status) *status = -2;
   return 0;
 }
 

Basic idea is that if you provide a __cxa_demangle function in your own program, it overrides the one from the standard library which is responsible for all the d_print_xxx function you can spot. I still have to stress this approach (right now, the provided alternative says “sorry: I couldn’t demangle that”, which should give you safely mangled names in exception reports. I haven’t seen any compiler flag to achieve the same result, but if anyone knows some, i’m interested.

I have your example program and replaced new with new(std::nothrow) and for extra measure replaced delete[] with ::operator delete[](ptr, std::nothrow) (Should be unnecessary since delete shouldn’t throw anyways right?). I actually noticed an increase in final executable size, although I am compiling into x64 not ARM so there may be other factors, still I would have thought the opposite. Assuming both are implemented in such a way that neither throw exceptions I would expect G++ to not compile RTTI and therefore the executable would be shorter. I do not have the time right not to inspect it further, perhaps they have their own set of bloat that is worse than RTTI or perhaps nothrow new in glib calls things that throw exceptions, or something else is causing the size increase independent of these two factors and rtti really isn’t being compiled in. I wish I had more time to investigate.

sylvainulg:
And i can read it the other way round, too: if we already have “new” in our program, using std:vector is 60KB “cheaper” than what one would suppose.

Yeah, that occurred to me also. I’m not sure what using RTTI yourself would do. Also, thanks for clearing up what impure does.

Ian:
Did you also test the nothrow overloaded version of new? It works like malloc in the sense that it returns NULL on failure instead of producing an exception.

I did try `ptr = new(nothrow) u8[8];‘, but that still gave me the full overhead. Maybe I didn’t do the test right.

Also it’s interesting to note that you can overwrite the new and delete operators in a class, and while it can be sketchy to overwrite them instead of using the library provided versions, I wonder if this would provide a way for automatic alignment for certain objects (Setting up the alignment then calling global new or something).

Btw, I investigated once the meaning of “impure” (http://sylvainhb.blogspot.com/2009/04/impuredata.html), which is basically all the state maintained by the library between two calls (such as the FILE* structures for stdin, stdout and stderr, for instance).