From: Paul Koning <Paul_Koning@dell.com>
To: dewar@adacore.com
Cc: schwab@suse.de, eliz@gnu.org, fche@redhat.com,
msnyder@vmware.com, brobecker@adacore.com,
jreiver@free.fr, gdb@sourceware.org
Subject: Re: how to examine data with compiler optimization option set?
Date: Thu, 04 Sep 2008 14:05:00 -0000 [thread overview]
Message-ID: <18623.60121.742830.903401@gargle.gargle.HOWL> (raw)
In-Reply-To: <48BFBE10.30902@adacore.com>
>>>>> "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
next prev parent reply other threads:[~2008-09-04 14:05 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-02 21:27 J R
2008-09-02 21:36 ` Robert Dewar
2008-09-02 21:45 ` jreiver
2008-09-02 21:50 ` Robert Dewar
2008-09-02 21:57 ` Joel Brobecker
2008-09-03 0:05 ` Michael Snyder
2008-09-03 1:53 ` Robert Dewar
2008-09-03 2:52 ` Daniel Jacobowitz
2008-09-03 14:35 ` Robert Dewar
2008-09-03 3:06 ` Frank Ch. Eigler
2008-09-03 4:37 ` Michael Snyder
2008-09-03 14:36 ` Robert Dewar
2008-09-03 18:34 ` Eli Zaretskii
2008-09-03 21:43 ` Robert Dewar
2008-09-04 8:01 ` Andreas Schwab
2008-09-04 10:53 ` Robert Dewar
2008-09-04 14:05 ` Paul Koning [this message]
2008-09-04 14:09 ` Robert Dewar
2008-09-04 14:15 ` Paul Koning
2008-09-04 14:17 ` Robert Dewar
2008-09-04 15:55 ` Eli Zaretskii
2008-09-04 18:13 ` Frank Ch. Eigler
2008-09-04 20:46 ` Ulrich Weigand
2008-09-03 0:04 ` Michael Snyder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18623.60121.742830.903401@gargle.gargle.HOWL \
--to=paul_koning@dell.com \
--cc=brobecker@adacore.com \
--cc=dewar@adacore.com \
--cc=eliz@gnu.org \
--cc=fche@redhat.com \
--cc=gdb@sourceware.org \
--cc=jreiver@free.fr \
--cc=msnyder@vmware.com \
--cc=schwab@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox