I like option B. It will be very helpful to reduce software product development time. Some software product just release with -O0 because they are not confident releasing a version differ to the one they were debugging and testing in.
Also in some systems -O0 simply doesn't work, which is too slow or is too big code size to fit into flash memory. Developer has to suffer poor debugability. I believe it valuable to have an option generating code with fair performance/code size but almost full debugability. And I believe it not technically impossible. Thanks - Joey -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J.C. Pizarro Sent: 2007年11月25日 7:46 To: gcc@gcc.gnu.org Subject: Re: Designs for better debug info in GCC. Choice A or B? To imagine that i'm using "-g -Os -finline-functions -funroll-loops". There are differences in how to generate "optimized AND debugged" code. A) Whole-optimized but with dirty debugged information if possible. ------------------------------------------------------------------------------------ When there is coredump from crash then its debugged information can be not complete (with losses) but can be readable for humans. This kind of strategy can't work well in "step to step" debuggers like gdb, ddd, kgdb, ... but its code is whole-optimized same as stripped program. B) Whole-debugged but partially optimized because of restricted requirements to maintain the full debugged information without losses. ------------------------------------------------------------------------------------ This kind of strategy works well in "step to step" debuggers like gdb, ddd, kgdb, ... but its code is less whole-optimized and bigger than stripped program. Sincerely, J.C.Pizarro
