Codegröße Fehlerbehandlung/Exceptions (C++)

[FelixW (Gast)]

Hallo Leute,

Folgendes Problem (C++, Newlib vorkompiliert, LPCXpresso, 
-fno-exceptions ):
erstelle ich ein Objekt mit "new" (oder ich definiere eine abstrakte 
Funktion -> mit Workaround gelöst)
so erhöht sich die Codegröße um ca. 70kB.

Anscheinend werden Routinen für eine Fehlerausgabe(Exceptions) 
eingebunden (printf, strcmp, __write, etc.)

Ich bräuchte Tipps, die Fehlerausgabe umzuleiten und selber zu 
behandeln, sodass der Code sich nicht so aufbläht?
Insbesondere "__cxa_demangle" ist über 40kB groß.

Danke Felix

Auszüge aus dem map-File (hoffentlich habe ich was verwertbares 
rausgesucht):

                              c:/nxp/lpcxpresso_5.2.4_2122/lpcxpresso/tools/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m\libstdc++.a(bad_alloc.o) (std::exception::~exception())
c:/nxp/lpcxpresso_5.2.4_2122/lpcxpresso/tools/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m\libstdc++.a(del_op.o)

                              c:/nxp/lpcxpresso_5.2.4_2122/lpcxpresso/tools/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m\libstdc++.a(vterminate.o) (__cxa_current_exception_type)
c:/nxp/lpcxpresso_5.2.4_2122/lpcxpresso/tools/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m\libstdc++.a(pointer_type_info.o)

c:/nxp/lpcxpresso_5.2.4_2122/lpcxpresso/tools/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m\libstdc++.a(cp-demangle.o)
                              c:/nxp/lpcxpresso_5.2.4_2122/lpcxpresso/tools/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m\libstdc++.a(vterminate.o) (__cxa_demangle)

                              c:/nxp/lpcxpresso_5.2.4_2122/lpcxpresso/tools/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m\libstdc++.a(cp-demangle.o) (realloc)
c:/nxp/lpcxpresso_5.2.4_2122/lpcxpresso/tools/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m\libc.a(lib_a-strncmp.o)
                              c:/nxp/lpcxpresso_5.2.4_2122/lpcxpresso/tools/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m\libstdc++.a(cp-demangle.o) (strncmp)

                              c:/nxp/lpcxpresso_5.2.4_2122/lpcxpresso/tools/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m\libstdc++.a(cp-demangle.o) (memcmp)
c:/nxp/lpcxpresso_5.2.4_2122/lpcxpresso/tools/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m\libc.a(lib_a-putc.o)



.text          0x00008200     0x9940 c:/nxp/lpcxpresso_5.2.4_2122/lpcxpresso/tools/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m\libstdc++.a(cp-demangle.o)
                0x00011a58                __cxa_demangle
                0x00011b1c                __gcclibcxx_demangle_callback

[Hannes W. (hannes_w)]

Schließt sich
> -fno-exceptions ):
und
> Fehlerausgabe(Exceptions)
nicht aus?

Was genau machst du?

Die Map-File nützt nix. Wenn etwas Code zu sehen wäre, müsste man nicht 
raten.
Willst du nun Exceptions oder nicht? Wenn ja, musst du mit dem Overhead 
leben. Wenn nicht, dann musst/kannst du sie auch nicht behandeln.
Ansonsten kann ich dich noch auf -fno-rtti hinweisen, falls das bei dir 
anwendbar ist.

[FelixW (Gast)]

> Schließt sich
> > -fno-exceptions ):
> und
> > Fehlerausgabe(Exceptions)
> nicht aus?

Anscheinend nicht. Meine Bibliothek ist als *.a vorkompiliert. 
Vermutlich ohne -fno-exceptions, -fno-rtti.

Compilerflag -fno-rtti ist gesetzt.

Beispiel A, 88kB im Flash; Ist mir zu groß (Kann nur bis 128kB debuggen)
Auf Exceptions kann ich verzichten, auf new möchte ich nur ungern 
verzichten. (Beispiel wird nicht so verwendet werden, da ziemlich 
sinnfrei ;) )

#include "ColorCIE.h"

int main(void) {
  setupHardware();
  ColorXYZ *col = new ColorXYZ();
  delete(col);
while(1);
}

Beispiel B, 11kB im Flash, schön klein, aber nur lokale Klasse

#include "ColorCIE.h"

int main(void) {
  setupHardware();
  ColorXYZ col = ColorXYZ();
while(1);
}

[Dr. Sommer (Gast)]

FelixW schrieb:
> aber nur lokale Klasse
lokale Klassen gibts nicht, das ist eine lokale Variable, wenn schon.
In C++ schreibt man übrigens üblicherweise "ColorXYZ col ();". Das 
kannst du auch außerhalb einer Funktion schreiben, s.d. die Variable von 
überall zugreifbar wird.
Sicher dass du "new" brauchst (wofür genau?) und das nicht nur aus 
einem Verständnis-Mangel oder Java-Gewohnheiten resultiert ;-)
Das Problem ist dass "new" Exceptions wirft. Du müsstest die 
entsprechende Stelle deiner libc finden und durch einen Dummy ersetzen 
der zB "while(1);" macht anstelle der Exception...

[temp (Gast)]

Also wenn man schon new und delete benutzt auf einem kleinen Controller, 
dann sollte man die entsprechenden Routinen auch selbst programmieren. 
Wer soll dir denn die Speicherverwaltung abnehmen? Die newlib? Die kennt 
weder deinen Controller noch deinen RAM. Hier muss was hin was der 
Aufgabenstellung angepasst ist, das kann keiner für dich entscheiden. 
Und wenn du nicht weißt wie das geht, dann sollte new und delete ein 
rotes Tuch für dich sein. Falls man FreeRtos verwendet kann es eine gute 
Idee sein sich an deren Speicherverwaltung mit dranzuhängen. 
Insbesondere wenn die neuere heap_4.c verwendet wird. Das sieht dann in 
etwa so aus:

// wird aus der Freertos Malloc Funktion gerufen
// wenn eine Speicheranforderung fehl schlägt
extern "C"
{
  void vApplicationMallocFailedHook( void )
   {
    while (1)
      {
      ;
      }
    }  
}    

// Abbildung der globalen new und delete-Handler
// auf die Malloc Funktionen von FreeRtos
// hier passiert auch die Verriegelung der Threads
void* operator new(size_t size)
{
  return pvPortMalloc(size);
}

void* operator new[](size_t size)
{
  return pvPortMalloc(size);
}

void  operator delete(void* pointer)
{
  vPortFree(pointer);
}
  
void  operator delete[](void* pointer)
{
  vPortFree(pointer);
}

[FelixW (Gast)]

Danke. Genau so eine (einfache) Lösung habe ich mir gewünscht. :)