This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Designs for better debug info in GCC. Choice A or B?


Ye, Joey wrote:

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.

The word "full" worries me a bit, I am afraid of it being interpreted as a requirement to be 100% "correct" in all cases, and this may be too severe. What we are looking for is good enough in practice, which is a vaguer criterion, but a more useful one. For instance as I mentioned early, i would be happy to live with not being able to reliably modify local variables.
------------------------------------------------------------------------------------
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]