This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Designs for better debug info in GCC
On Nov 7, 2007, Mark Mitchell <mark@codesourcery.com> wrote:
> Until we all know what we're trying to do
Here's what I am trying to do:
1. Ensure that, for every user variable for which we emit debug
information, the information is correct, i.e., if it says the value of
a variable at a certain instruction is at certain locations, or is a
known constant, then the variable must not be at any other location at
that point, and the locations or values must match reasonable
expectations based on source code inspection.
2. Defining "reasonable expectations" is tricky, for code reordering
typical of optimization can make room for numerous surprises. I don't
have a precise definition for this yet, but very clearly to me saying
that a variable holds a value that it couldn't possibly hold (e.g.,
because it is only assigned that value in a code path that is
knowingly not taken) is a very clear indication that something is
amiss. The general guiding rule is, if we aren't sure the information
is correct (or we're sure it isn't), we shouldn't pretend that it is.
3. Try to ensure that, if the value of a variable is a known constant
at a certain point in the program, this information is present in
debug information.
4. Try to ensure that, if the value of a variable is available at any
location at a certain point in the program, this information is
present in debug information.
5. Stop missing optimizations for the sake of improving debug
information.
6. Avoid using additional memory and CPU cycles that would be needed
only for debug information when compiling without generating debug
information
--
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}