On Nov 7, 2007, Mark Mitchell <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
