This is the mail archive of the gcc@gcc.gnu.org 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 Dec 17, 2007, Geert Bosch <bosch@adacore.com> wrote:

> We could conceptually have inspection points between each source
> statement and declaration, which would roughly correspond to a
> use of all memory and all source variables, wether in memory or
> in registers.
> These inspections points would be considered potentially trapping.

Yes, I've considered something along these lines, but decided against
it, for we can't afford for debug information to affect executable
code generation in any way whatsoever, and we don't want to pessimize
optimized code when compiling without -g just so that compiling with
-g would get us the same code.

> Also, since no user-visible state can be modified by speculatively
> executed instructions such as loads, such instructions should not
> be tagged with their original source location information.

Line number information has a well-defined meaning: it ought to
represent the source code line that best represents the source-code
construct that ended up implemented using that instruction.

To address what we have in mind, there's an additional annotation on
top of line number information: the is_stmt flag.  This is what we
should use to tell debuggers what the best instruction is to set a
breakpoint at a certain line number or so, and for debuggers to be
able to step line by line more seamlessly.

-- 
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}


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