> On the SPARC, this produced an executable I couldn't run > on the simulator. It looked like the .text segment may > have increased enough to not fit in the simulator.
Weird. The EH tables should probably not end up in .text. > So this appears to work around the build time problem and > will let me continue to test the real changes I was working > on but I don't know that I like this as a permanent solution. This setting should bring the Ada compiler on par with the C++ compiler as far as the EH mechanism is concerned: same space overhead, same performance overhead. Which EH mechanism do you use for C++ in RTEMS? > I have seen reports where people complained about the size > of embedded GNAT and GNAT/RTEMS executables and doubling > the code size just makes it worse. It's a tradeoff between space and performance. Certainly EH tables can be large and setjmp/longjmp EH might be better suited, albeit slower. > But this is progress and gives a real hint as to the underlying > problem. Maybe it is enough for someone to fix it. It's not really related to the problem though, which appears to be in DF. But at least it makes it possible to reproduce it even on platforms where it doesn't arise natively, by making the opposite change you made. > Is there a PR for this or do I need to try to file one? No, I don't think there is one. -- Eric Botcazou
