This is the mail archive of the 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

On Nov 12, 2007, Joe Buck <Joe.Buck@synopsys.COM> wrote:

> consider dropping observable points where the states will not match.

We can't really do that.  The line number mapping is from PC to line
number, regardless of how far into the execution or earlier lines the
code is.  Omitting certain mappings from PC to line numbers would be

The piece of the puzzle we're still missing is how to get debuggers
clever enough to decide where to set a breakpoint.  Nowadays,
debuggers (at least those I'm familiar with) tend to set breakpoints
at the lowest-numbered PC corresponding to a given source line number.
While this is useful at times, at other times what you want is the
lowest PC after all instructions corresponding to the previous line,
because at that point you know all the state of the previous line
should be stable and hopefully still observable.  Or something along
these lines.  I don't have a complete solution for this problem.  It's
very far from trivial, and I don't see that debug information can
carry enough information for the compiler to aid the debugger in
selecting where to place breakpoints in this regard.

Alexandre Oliva
FSF Latin America Board Member
Red Hat Compiler Engineer   aoliva@{,}
Free Software Evangelist  oliva@{,}

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