On Nov 24, 2007, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > hat is indeed the problem, but I'm not sure your requirement is > feasible. If we permit DECL_UID divergence, it means we can't use > DECL_UID for hashing any more. Since they already stand for hashable > proxies for the decl pointers, I don't see what we'd gain by > introducing yet another hashable uid that's stable across -g. > > What do you suggest us to use for hashing? Or do you suggest us to do > away with hashing and use sorted set or map data structures? > > -- > Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ > FSF Latin America Board Member http://www.fsfla.org/ > Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} > Free Software Evangelist [EMAIL PROTECTED], gnu.org}
( i posted this message but doesn't appear in http://gcc.gnu.org/ml/gcc/2007-11/ , i don't know why? ) 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
