Re: PR 23551: why should we coalesce inlined variables?

[Alexandre Oliva <aoliva at redhat dot com>]

On Jul 10, 2007, "Dave Korn" <dave.korn@artimi.com> wrote:

> Or are these half-open ranges?
 
Yup, that's how ranges work in dwarf2+ debug info.

>> Is there any reason not to do it this way?

>   Is there any reason /to/ do it this way?

Sure, to be able to emit correct ranges.

> As far as I can tell, you want to
> make the source-level debugging at O2 look exactly like the source level
> debugging at O0

Not quite.  I just need us to denote the values of variables whose
values are available.

> inserting bogus debug information

What's bogus about emitting the information the way specified in the
relevant debug info standard?

> they're stepping through lines of code that don't actually exist?

The lines exist, of course, but I understand what you mean.  But no,
I'm not talking about emitting nops or any such thing just to enable
someone to step into any particular line.  It would be at most a label
and debug information to reflect what the compiler actually did to the
user's variable.

I gave an example before of setting a breakpoint at (or before) a line
that had been completely optimized away.  If you took that as meaning
that, if you tried to set a breakpoint at the line that had no code
generated for it, you'd get anything different from what you get
today, I apologize for not being clear about what I meant.  I meant
that, if you set a breakpoint at that point or before, where the
variable would be expected to hold a certain value, you'd get that
value or an indication it was optimized away, but not something else.

> what happens when the user wants to set a breakpoint on line 1 and
> see the value of foo being assigned to bar?

If there's no instruction to set a breakpoint on, user can't set a
breakpoint there, no change here.

The debug info I'm talking about provides information about
source-level concepts for instructions generated by the compiler.

> Someone who wants to analyze their code as it is written rather than
> as it is compiled should be using static analysis or generating
> debug from a -O0 compilation.

http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00766.html

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