Am 31.08.2010 23:04, schrieb Stu Bell: >> I doubt there's a >> very broad audience for improved stackframes -- as I said, >> people do care for the amount of code generated, next they do >> care for the code size, then they compare the generated code >> size with compiler XYZ, and only then they start comparing >> other features. :-/ > > For some users, I'm sure this is true. For others (such as me), an > ability to show a stack trace would be a godsend. Not everyone is > trying to fit code into an ATtiny or ATmega8! I specifically chose the > ATmega2560 and added external SRAM so I would not have to worry about > memory resources (as much). If I could trade SRAM efficiency for a > stack trace, especially as a compile-time option, I would take it!
This is exactly what I am looking for, too, as I am in exactly the same situation, just using an Xmega128a1 here. Memory and flash space is a secondary interest for me while finding bugs during development has a very high priority. Once it all works, I can just compile without -fno-omit-frame-pointer and it would even have the low flash and lower RAM requirements, but development would be greatly improved. > Eh, such is life. Since I don't have them, I live without them. But > just because I don't have stack traces (...and a Lotus Elise ;-) ), > don't believe for a minute that I don't wish for them! Maybe we'll get it done. If the compiler support were there, it would all play out nicely :-) I'm still quite optimistic, it really cannot be that hard to change IMHO. Kind regards, Johannes _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
