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

["J.C. Pizarro" <jcpiza at gmail dot com>]

On Nov 24, 2007, Alexandre Oliva <aoliva@redhat.com> 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   aoliva@{redhat.com, gcc.gnu.org}
> Free Software Evangelist  oliva@{lsd.ic.unicamp.br, 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