This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: Designs for better debug info in GCC. Choice A or B?
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: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] 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