9

I'm working on an embedded platform, and I'm not comfortable adding 60k to my binary. There are arguments to avoid exceptions on embedded system anyway, but I think most of them are spurious. Exceptions make sense, but I can't justify the cost as it stands. I'm using gcc 4.6.3, maybe I'm missing an option, or maybe this is just the overhead of exceptions. I've tried -Os, and changing the exceptions to longjmp, but to no avail. I might have missed something.

Thanks for any insight.

Kendrick Taylor
  • 2,168
  • 2
  • 14
  • 20
  • 6
    *"Exceptions make sense, but I can't justify the cost as it stands"* - Well then, they don't really make sense in this context, do they? Bot approaches have pros and cons, but there's nothing wrong with using error codes (aside from a lot of added boilerplate code). It's much easier to get those right as well. – Ed S. Feb 07 '13 at 21:45
  • This may help http://stackoverflow.com/questions/998248/how-can-i-stop-g-from-linking-unwanted-exception-handling-code – Gearoid Murphy Feb 07 '13 at 21:51
  • @EdS. No, you're right. They don't make sense, as the cost currently stands, so I'm currently not using them. My question is if I can lower the cost somehow. I'm using error codes right now. – Kendrick Taylor Feb 07 '13 at 21:56
  • @GearoidMurphy Thanks for the link. I'm already compiling without exceptions, but a good resource regardless. – Kendrick Taylor Feb 07 '13 at 21:56
  • You may be able to reduce the binary footprint further by following these steps http://stackoverflow.com/questions/6687630/c-c-gcc-ld-remove-unused-symbols – Gearoid Murphy Feb 07 '13 at 22:01
  • in the expanse of a real application, what is 60k? – Sellorio Feb 07 '13 at 22:04
  • 1
    @MrUniverse: A lot when you have 256k of memory to work with. I've worked on platforms with less. – Ed S. Feb 07 '13 at 22:16
  • @EdS. this century? ok in that case, it def is not worth it. – Sellorio Feb 07 '13 at 22:41
  • @MrUniverse: Yes. Not all software development is deployed on a PC or smart phone. There are still plenty of very small, embedded devices. I work with them regularly. – Ed S. Feb 07 '13 at 22:42
  • @EdS. sounds more interesting, a greater challenge. I like having optimised code and all that (i still think its important despite powerful devices). – Sellorio Feb 07 '13 at 22:51
  • 1
    @MrUniverse: It is fun in a way (and I like writing software that makes physical entities move around, light up, etc.). It can get frustrating at times though... we once had to rewrite a code generation engine because the code it was generating was just too big. – Ed S. Feb 07 '13 at 22:54
  • @EdS. Agreed! But there might be better options to reduce code size than throwing away RTTI and exception handling, though. E.g. `GCC newlib` standard implementations might not always provide what you want to do in detail, and you might be able to 'override' it. – πάντα ῥεῖ Feb 07 '13 at 23:09
  • @g-makulik: True, it just depends. – Ed S. Feb 07 '13 at 23:17

2 Answers2

2

At 1st, no!

Exception handling comes with some cost, mainly by requiring RTTI support primarily IMHO (didn't prove this experimentally so far). RTTI support will lead to some expense use of your code's text segment, especially if there are a lot of template instantiations (e.g. using STL templated classes/container-classes extensively with lot of various types).

On the other hand, compared to other possibilities to reduce e.g. newlib required implementations, the cost of 60k overhead is not so much.

You really should think twice about letting exception support go!

Funny enough, I've discussed this topic with my colleagues today, when we where facing an error that was obviously caused by an out of memory situation. The firmware in question (and it's OS bindings to FreeRTOS) don't support exceptions, but memory management implementation would trigger a processor exception, if you cannot acquire a certain amount of heap memory using new(). This might happen using some STL induced algorithm, and you have no chance to intercept this using a try/catch block on failure (e.g. usage of a simple std::vector).

So you should decide how you might handle error situations, without using exceptions or not, and being sure to provide consistent behavior e.g. for usage of common STL patterns, etc., and weigh this out of the cost you pay for .text section size.

πάντα ῥεῖ
  • 83,259
  • 13
  • 96
  • 175
2

You can turn off exceptions in GCC using -fno-exceptions.

However, you can't have your cake and eat it too. Turning off exceptions means you can't catch them, and it will also break if you link against code compiled with exceptions on. But it does reduce the binary size as you intended.

Code without exceptions (but with the same level of error checking) is ugly as sin but it's a price you have to pay.

Lovely exception-free robust code example in C :)

error_t foo(void) {
    if (!do_foo()) {
        error_code = E_FOO;
        goto bail;
    }
    if (!do_bar()) {
        error_code = E_BAR;
        goto bail;
    }
    /* repeat 100 times */
bail:
    cleanup();
    return error_code;
}
congusbongus
  • 10,870
  • 5
  • 64
  • 86
  • That wouldn't enable the OP to actually **use** exceptions as he/she requires. Yes you can't have the cake while eating it ... – πάντα ῥεῖ Feb 07 '13 at 23:01
  • Better measure if the added obfuscation really buys you anything size-wise (the extra error handling code shows up too). – vonbrand Feb 07 '13 at 23:03
  • @vonbrand No need to measure, the difference is in the order of 60k. The size difference between equivalent try/catch/throws and if/cleanup/errors is negligible. – congusbongus Feb 07 '13 at 23:26
  • @CongXu, I'm not so sure, both are rather complex (compiler generated or handwritten). And there might also be some runtime overhead for stack unwinding. – vonbrand Feb 08 '13 at 00:00