how to examine data with compiler optimization option set?

how to examine data with compiler optimization option set?

[J R]

Extract of GDB user manual:

"Another possible effect of compiler optimizations is to optimize unused
variables out of existence, or assign variables to registers (as opposed to
memory addresses). Depending on the support for such cases offered by the debug
info format used by the compiler, GDB might not be able to display values for
such local variables.

To solve such problems, either recompile without optimizations, or use a
different debug info format, if the compiler supports several such formats. For
example, GCC, the GNU C/C++ compiler usually supports the `-gstabs' option.
`-gstabs' produces debug info in a format that is superior to formats such as
COFF. You may be able to use DWARF2 (`-gdwarf-2'), which is also an effective
form for debug info. See section `Options for Debugging Your Program or GNU CC'
in Using GNU CC, for more information."

I wanted to keep the optimization option, so I tried to recompile with GCC,
using the -gstabs and -gdwarf-2 options, and even -g3, with this very simple
program:
int main(void){
	int a = 1;
	int b = 2;
	int c = a+b;

	printf("Value c = %d \n", c);
}

But still couldn't display the variables a, b and c!

Is there a particular compiling option configuration to set?

Many thanks in advance.

Regards.

Re: how to examine data with compiler optimization option set?

[Robert Dewar]

J R wrote:
> Extract of GDB user manual:
> 
> "Another possible effect of compiler optimizations is to optimize unused
> variables out of existence, or assign variables to registers (as opposed to
> memory addresses). Depending on the support for such cases offered by the debug
> info format used by the compiler, GDB might not be able to display values for
> such local variables.
> 
> To solve such problems, either recompile without optimizations, or use a
> different debug info format, if the compiler supports several such formats. For
> example, GCC, the GNU C/C++ compiler usually supports the `-gstabs' option.
> `-gstabs' produces debug info in a format that is superior to formats such as
> COFF. You may be able to use DWARF2 (`-gdwarf-2'), which is also an effective
> form for debug info. See section `Options for Debugging Your Program or GNU CC'
> in Using GNU CC, for more information."
> 
> I wanted to keep the optimization option, so I tried to recompile with GCC,
> using the -gstabs and -gdwarf-2 options, and even -g3, with this very simple
> program:
> int main(void){
> 	int a = 1;
> 	int b = 2;
> 	int c = a+b;
> 
> 	printf("Value c = %d \n", c);
> }
> 
> But still couldn't display the variables a, b and c!

That's because if you ask for the compiler to optimize, it
will change this program to

      int main(void){
         printf ("Value c = %d \n", 3");
      }

if it was a bit cleverer, it might even change it to

      int main(void){
         printf ("Value c = 3 \n");
      }

but in either case a,b, and c are gone!

It might be theoretically possible to retain the values of
a,b,c in the debugging information, but this is a huge amount
of work, and not something likely to be done in the near future.

> Is there a particular compiling option configuration to set?

Yes,  -O0, if you want junk code kept around for debugging
purposes, you have to ask for it!
> 
> Is there a particular compiling option configuration to set?
> 
> Many thanks in advance.
> 
> Regards.

Re: how to examine data with compiler optimization option set?

[jreiver]

Yes, I knew that the optimization option removes the visibility for a, b and c.
But GDB user manual seemed to say that you can still view them with providing
-gstabs or -gdwarf2 option, in addition to the -O[1|2|3] option you might want
to keep.

Isn't that possible at all? (I am currently evaluating the debugging facilities
of gdb)

Regards,

J R

Quoting Robert Dewar <dewar@adacore.com>:

> J R wrote:
> > Extract of GDB user manual:
> >
> > "Another possible effect of compiler optimizations is to optimize unused
> > variables out of existence, or assign variables to registers (as opposed to
> > memory addresses). Depending on the support for such cases offered by the
> debug
> > info format used by the compiler, GDB might not be able to display values
> for
> > such local variables.
> >
> > To solve such problems, either recompile without optimizations, or use a
> > different debug info format, if the compiler supports several such formats.
> For
> > example, GCC, the GNU C/C++ compiler usually supports the `-gstabs' option.
> > `-gstabs' produces debug info in a format that is superior to formats such
> as
> > COFF. You may be able to use DWARF2 (`-gdwarf-2'), which is also an
> effective
> > form for debug info. See section `Options for Debugging Your Program or GNU
> CC'
> > in Using GNU CC, for more information."
> >
> > I wanted to keep the optimization option, so I tried to recompile with GCC,
> > using the -gstabs and -gdwarf-2 options, and even -g3, with this very
> simple
> > program:
> > int main(void){
> > 	int a = 1;
> > 	int b = 2;
> > 	int c = a+b;
> >
> > 	printf("Value c = %d \n", c);
> > }
> >
> > But still couldn't display the variables a, b and c!
>
> That's because if you ask for the compiler to optimize, it
> will change this program to
>
>       int main(void){
>          printf ("Value c = %d \n", 3");
>       }
>
> if it was a bit cleverer, it might even change it to
>
>       int main(void){
>          printf ("Value c = 3 \n");
>       }
>
> but in either case a,b, and c are gone!
>
> It might be theoretically possible to retain the values of
> a,b,c in the debugging information, but this is a huge amount
> of work, and not something likely to be done in the near future.
>
> > Is there a particular compiling option configuration to set?
>
> Yes,  -O0, if you want junk code kept around for debugging
> purposes, you have to ask for it!
> >
> > Is there a particular compiling option configuration to set?
> >
> > Many thanks in advance.
> >
> > Regards.
>
>

Re: how to examine data with compiler optimization option set?

[Robert Dewar]

jreiver@free.fr wrote:
> Yes, I knew that the optimization option removes the visibility for a, b and c.
> But GDB user manual seemed to say that you can still view them with providing
> -gstabs or -gdwarf2 option, in addition to the -O[1|2|3] option you might want
> to keep.

It does not say that, it says that "depending on the support for such 
cases offered by the debug format" ... it does not imply or state that
any debug format will be able to preserve the information (in the
general case it is enormously difficult to preserve this information).
> 
> Isn't that possible at all? (I am currently evaluating the debugging facilities
> of gdb)
> 

No it is not possible.

Re: how to examine data with compiler optimization option set?

[Joel Brobecker]

The documentation is slightly outdated, as stabs has hardly any support
for debugging optimized code.  Better stick with DWARF2/3.

> >Isn't that possible at all? (I am currently evaluating the debugging 
> >facilities
> >of gdb)
> 
> No it is not possible.

Note that the debugger behavior is usually expected considering
the debugging information generated by the compiler. I heard there
is some effort to improve the debugging information, but generally
speaking, debugging optimized code right now can be tricky.

-- 
Joel

Re: how to examine data with compiler optimization option set?

[Michael Snyder]

jreiver@free.fr wrote:
> Yes, I knew that the optimization option removes the visibility for a, b and c.
> But GDB user manual seemed to say that you can still view them with providing
> -gstabs or -gdwarf2 option, in addition to the -O[1|2|3] option you might want
> to keep.

What it means to say is that you MIGHT still be able
to view them, if you happen to get lucky.

It does not offer any guarantee.

Re: how to examine data with compiler optimization option set?

[Michael Snyder]

Joel Brobecker wrote:
> The documentation is slightly outdated, as stabs has hardly any support
> for debugging optimized code.  Better stick with DWARF2/3.
> 
>>> Isn't that possible at all? (I am currently evaluating the debugging
>>> facilities
>>> of gdb)
>> No it is not possible.
> 
> Note that the debugger behavior is usually expected considering
> the debugging information generated by the compiler. I heard there
> is some effort to improve the debugging information, but generally
> speaking, debugging optimized code right now can be tricky.

I don't think there is any possibility whatsoever of
somehow generating location codes for the variables in
the example.

Those values are simply not kept anywhere.  GCC will replace
them all with the constant, "3".

Re: how to examine data with compiler optimization option set?

[Robert Dewar]

Michael Snyder wrote:

> I don't think there is any possibility whatsoever of
> somehow generating location codes for the variables in
> the example.

It *is* theoretically possible to generate such information,
but I agree with Michael that in practice it is too far
out of scope to ever happen.
> 
> Those values are simply not kept anywhere.  GCC will replace
> them all with the constant, "3".

Re: how to examine data with compiler optimization option set?

[Daniel Jacobowitz]

On Tue, Sep 02, 2008 at 09:52:21PM -0400, Robert Dewar wrote:
> Michael Snyder wrote:
>
>> I don't think there is any possibility whatsoever of
>> somehow generating location codes for the variables in
>> the example.
>
> It *is* theoretically possible to generate such information,
> but I agree with Michael that in practice it is too far
> out of scope to ever happen.

Last I checked Alex was considering implementing it... so I wouldn't
be too sure :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: how to examine data with compiler optimization option set?

[Frank Ch. Eigler]

Michael Snyder <msnyder@vmware.com> writes:

> [...]
> I don't think there is any possibility whatsoever of
> somehow generating location codes for the variables in
> the example.
>
> Those values are simply not kept anywhere.  GCC will replace
> them all with the constant, "3".

You might be surprised.  Some RH engineers are working along these
lines.  Being able to debug (<=> probe/trace) optimized code is
becoming more and more important, and gcc is slowly getting into the
mood to help.


- FChE

Re: how to examine data with compiler optimization option set?

[Michael Snyder]

On Tue, 2008-09-02 at 23:04 -0400, Frank Ch. Eigler wrote:
> Michael Snyder <msnyder@vmware.com> writes:
> 
> > [...]
> > I don't think there is any possibility whatsoever of
> > somehow generating location codes for the variables in
> > the example.
> >
> > Those values are simply not kept anywhere.  GCC will replace
> > them all with the constant, "3".
> 
> You might be surprised.  Some RH engineers are working along these
> lines.  Being able to debug (<=> probe/trace) optimized code is
> becoming more and more important, and gcc is slowly getting into the
> mood to help.

I'm more than willing to be surprised...
it will be a pleasant one.  ;-)

Re: how to examine data with compiler optimization option set?

[Robert Dewar]

Daniel Jacobowitz wrote:

> Last I checked Alex was considering implementing it... so I wouldn't
> be too sure :-)
> 

That's of course great, but implementing this in full generality
is a very complex task!

Re: how to examine data with compiler optimization option set?

[Robert Dewar]

Frank Ch. Eigler wrote:

> You might be surprised.  Some RH engineers are working along these
> lines.  Being able to debug (<=> probe/trace) optimized code is
> becoming more and more important, and gcc is slowly getting into the
> mood to help.
> 
> 
> - FChE

Well sure, but demanding to be able to see every variable at
every point is more than the minimum needed.

To me the most critical thing would be to make sure that
parameters never get lost in the back trace, or when
there is a breakpoint on a function entry. That would
go far enough.

Then you have to worry about control flow issues, such
as inlining and tail merging and that's also not easy.

Re: how to examine data with compiler optimization option set?

[Eli Zaretskii]

> Cc: Joel Brobecker <brobecker@adacore.com>, Robert Dewar <dewar@adacore.com>,         "jreiver@free.fr" <jreiver@free.fr>,         "gdb@sourceware.org" <gdb@sourceware.org>
> From: fche@redhat.com (Frank Ch. Eigler)
> Date: Tue, 02 Sep 2008 23:04:24 -0400
> 
> You might be surprised.  Some RH engineers are working along these
> lines.  Being able to debug (<=> probe/trace) optimized code is
> becoming more and more important, and gcc is slowly getting into the
> mood to help.

I'll applaud this mood.  When I started using GCC (it was v1.x back
then), being able to efficiently debug optimized code was one of GCC's
most attractive features.  When that feature was lost in GCC 3.x, I
was quite shocked.  I'd love to have that back again.

Re: how to examine data with compiler optimization option set?

[Robert Dewar]

Eli Zaretskii wrote:
>> Cc: Joel Brobecker <brobecker@adacore.com>, Robert Dewar <dewar@adacore.com>,         "jreiver@free.fr" <jreiver@free.fr>,         "gdb@sourceware.org" <gdb@sourceware.org>
>> From: fche@redhat.com (Frank Ch. Eigler)
>> Date: Tue, 02 Sep 2008 23:04:24 -0400
>>
>> You might be surprised.  Some RH engineers are working along these
>> lines.  Being able to debug (<=> probe/trace) optimized code is
>> becoming more and more important, and gcc is slowly getting into the
>> mood to help.
> 
> I'll applaud this mood.  When I started using GCC (it was v1.x back
> then), being able to efficiently debug optimized code was one of GCC's
> most attractive features.  When that feature was lost in GCC 3.x, I
> was quite shocked.  I'd love to have that back again.

Well you always had local variables disappearing in earlier versions
but enough worked so you could debug, in particular parameters were
always available and reliable.

Re: how to examine data with compiler optimization option set?

[Andreas Schwab]

Robert Dewar <dewar@adacore.com> writes:

> Well you always had local variables disappearing in earlier versions
> but enough worked so you could debug, in particular parameters were
> always available and reliable.

If parameters are passed in registers they are very likely to get lost.
Even on i386 parameters sometimes get passed in registers, eg. when
calling local functions.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: how to examine data with compiler optimization option set?

[Robert Dewar]

Andreas Schwab wrote:
> Robert Dewar <dewar@adacore.com> writes:
> 
>> Well you always had local variables disappearing in earlier versions
>> but enough worked so you could debug, in particular parameters were
>> always available and reliable.
> 
> If parameters are passed in registers they are very likely to get lost.
> Even on i386 parameters sometimes get passed in registers, eg. when
> calling local functions.

Yes, indeed parameters do get lost and I find it impossible in
practice to debug at -O1 (whereas this was ny normal practice
for many years).

What I am saying is that if an effort is put in to improve
the debugging information, for me this would be the primary
target.
> 
> Andreas.
> 

Re: how to examine data with compiler optimization option set?

[Paul Koning]

>>>>> "Robert" == Robert Dewar <dewar@adacore.com> writes:

 Robert> Andreas Schwab wrote:
 >> Robert Dewar <dewar@adacore.com> writes:
 >> 
 >>> Well you always had local variables disappearing in earlier
 >>> versions but enough worked so you could debug, in particular
 >>> parameters were always available and reliable.
 >>  If parameters are passed in registers they are very likely to get
 >> lost.  Even on i386 parameters sometimes get passed in registers,
 >> eg. when calling local functions.

 Robert> Yes, indeed parameters do get lost and I find it impossible
 Robert> in practice to debug at -O1 (whereas this was ny normal
 Robert> practice for many years).

 Robert> What I am saying is that if an effort is put in to improve
 Robert> the debugging information, for me this would be the primary
 Robert> target.

Is the problem inadequate debug information (i.e., the values are
there, but there isn't debug data that points to the correct registers
or stack slots) -- or is the problem that the values you want to see
are dead by the time you get to them and the registers holding them
have been reused by then?   Or something in between, i.e., the values
are technically dead, but the registers have NOT yet been reused so
the debug information can (and should) still show where they are.

    paul

Re: how to examine data with compiler optimization option set?

[Robert Dewar]

Paul Koning wrote:

> Is the problem inadequate debug information (i.e., the values are
> there, but there isn't debug data that points to the correct registers
> or stack slots) -- or is the problem that the values you want to see
> are dead by the time you get to them and the registers holding them
> have been reused by then?   Or something in between, i.e., the values
> are technically dead, but the registers have NOT yet been reused so
> the debug information can (and should) still show where they are.

Well on entry to a function, (if you breakpoint on entry), the
parameters cannot have been overwritten yet I would think!
> 
>     paul

Re: how to examine data with compiler optimization option set?

[Paul Koning]

>>>>> "Robert" == Robert Dewar <dewar@adacore.com> writes:

 Robert> Paul Koning wrote:
 >> Is the problem inadequate debug information (i.e., the values are
 >> there, but there isn't debug data that points to the correct
 >> registers or stack slots) -- or is the problem that the values you
 >> want to see are dead by the time you get to them and the registers
 >> holding them have been reused by then?  Or something in between,
 >> i.e., the values are technically dead, but the registers have NOT
 >> yet been reused so the debug information can (and should) still
 >> show where they are.

 Robert> Well on entry to a function, (if you breakpoint on entry),
 Robert> the parameters cannot have been overwritten yet I would
 Robert> think!

Agreed.

I haven't run into trouble there (on MIPS that is), provided the
breakpoint is set after the function prologue.

	   paul

Re: how to examine data with compiler optimization option set?

[Robert Dewar]

Paul Koning wrote:
>>  Robert> Well on entry to a function, (if you breakpoint on entry),
>  Robert> the parameters cannot have been overwritten yet I would
>  Robert> think!
> 
> Agreed.
> 
> I haven't run into trouble there (on MIPS that is), provided the
> breakpoint is set after the function prologue.

I am sure this is a target specific problem, I am using
x86 windows.
> 
> 	   paul
> 

Re: how to examine data with compiler optimization option set?

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: Eli Zaretskii <eliz@gnu.org>,
> 	"Frank Ch. Eigler" <fche@redhat.com>, msnyder@vmware.com,
> 	brobecker@adacore.com, jreiver@free.fr, gdb@sourceware.org
> Date: Thu, 04 Sep 2008 10:00:45 +0200
> 
> If parameters are passed in registers they are very likely to get lost.

Then the compiler should, under -ggdb, emit code and debug info that
allow GDB finding these parameters somewhere.

Failing that, there should be a compiler switch to disable this
optimization, and that switch should be enabled by default when one
uses -ggdb.

In many real-life programs the net effect of this optimization is
negligibly small, while the effect of not being able to see function
arguments means the program either gets shipped less debugged or is
built without optimizations and shipped that way.  I know _I_ would
happily give up this optimization if I could get back the lost ability
of debugging reasonably well optimized code.

Re: how to examine data with compiler optimization option set?

[Frank Ch. Eigler]

Hi -

On Thu, Sep 04, 2008 at 06:55:15PM +0300, Eli Zaretskii wrote:
> [...]
> > If parameters are passed in registers they are very likely to get lost.
> 
> Then the compiler should, under -ggdb, emit code and debug info that
> allow GDB finding these parameters somewhere.

And it should.

> [...]  I know _I_ would happily give up this optimization if I could
> get back the lost ability of debugging reasonably well optimized
> code.

You shouldn't have to give up too much.  gcc just needs to try harder.
If you guys want to help provide some data & testing help, please
check out Alex Oliva's var-tracking gcc branch.

- FChE

Re: how to examine data with compiler optimization option set?

[Ulrich Weigand]

Frank Ch. Eigler wrote:

> On Thu, Sep 04, 2008 at 06:55:15PM +0300, Eli Zaretskii wrote:
> > [...]
> > > If parameters are passed in registers they are very likely to get lost.
> > 
> > Then the compiler should, under -ggdb, emit code and debug info that
> > allow GDB finding these parameters somewhere.
> 
> And it should.

Current GCC policy is that -g never changes anything in the emitted code.
If you build with and without -g and then strip the binaries, they are
supposed to be identical.  This seems a useful property to me ...

However, this is not to say there couldn't be some other option that
did change code generation like that.  (In any case, even without 
changing code generation, there seems to be a lot of possibilities
to simply generate better debug info describing what's there!)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com