From: Andrew STUBBS <andrew.stubbs@st.com>
To: Jim Blandy <jimb@red-bean.com>
Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sources.redhat.com
Subject: Re: [RFC] Alternate approach to keeping convenience variables
Date: Tue, 24 Jan 2006 11:44:00 -0000 [thread overview]
Message-ID: <43D60D20.2080004@st.com> (raw)
In-Reply-To: <8f2776cb0601231429y38714c9bm830991b4b037ec70@mail.gmail.com>
Jim Blandy wrote:
> The $trace_frame variable is set to -1 when GDB starts, which
> indicates that there's no trace frame selected. I think it would be a
> little more helpful for the variables to always exist: you can write
> user-defined commands that give a reasonable error message, for
> example. GDB doesn't have any way (?) to check whether a convenience
> variable has been initialized yet.
A newly created convenience variable has the value 'void'. (A variable
is created the first time it is referenced, even as an rvalue.)
Therefore, if it is 'void' it can be considered uninitialised.
This is how the 'init-if-undefined' command works.
The only way (I know of) to set it back to 'void', once assigned another
value, is to assign the value of another uninitialised variable, which I
would consider as copying the undefined status as well as the value 'void'.
So an example GDB script fragment to check a variable might look like this:
set $temp = $trace_frame
init-if-undefined $temp = 99999
if $temp == 99999
Copying the value to $temp ensures that the original variable
$trace_frame remains undamaged.
HTH
Andrew Stubbs
next prev parent reply other threads:[~2006-01-24 11:44 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-21 22:05 [PATCH] keeping convenience variables (take 2) Andrew STUBBS
2005-11-22 4:58 ` Eli Zaretskii
2005-11-22 8:43 ` Jim Blandy
2005-11-22 19:27 ` Andrew STUBBS
2005-12-10 4:46 ` [RFC] Alternate approach to keeping convenience variables Daniel Jacobowitz
2005-12-10 5:07 ` Jim Blandy
2005-12-10 8:24 ` Daniel Jacobowitz
2005-12-10 22:20 ` Jim Blandy
2005-12-11 18:12 ` Eli Zaretskii
2005-12-11 19:17 ` Eli Zaretskii
2006-01-23 22:29 ` Jim Blandy
2006-01-24 11:44 ` Andrew STUBBS [this message]
2006-01-24 18:41 ` Jim Blandy
2006-01-24 18:43 ` Daniel Jacobowitz
2006-01-24 19:16 ` Jim Blandy
2006-01-24 19:24 ` Daniel Jacobowitz
2006-01-25 0:13 ` Jim Blandy
2006-01-24 19:45 ` Andrew STUBBS
2006-01-04 12:17 ` Andrew STUBBS
2006-01-04 17:00 ` Jim Blandy
2006-01-04 17:48 ` Andrew STUBBS
2006-01-04 18:37 ` Jim Blandy
2006-01-22 21:04 ` Daniel Jacobowitz
2006-01-22 21:31 ` Daniel Jacobowitz
2006-01-23 22:46 ` Jim Blandy
2006-01-27 17:53 ` Eli Zaretskii
2006-01-27 18:12 ` Jim Blandy
2006-01-27 18:29 ` Eli Zaretskii
2006-01-27 18:41 ` Joel Brobecker
2006-02-01 23:14 ` Daniel Jacobowitz
2006-02-02 4:18 ` Eli Zaretskii
2006-02-06 22:14 ` Daniel Jacobowitz
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=43D60D20.2080004@st.com \
--to=andrew.stubbs@st.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=jimb@red-bean.com \
/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