From: Andrew STUBBS <andrew.stubbs@st.com>
To: GDB Patches <gdb-patches@sourceware.org>
Subject: [PATCH] Initialise data to appease valgrind
Date: Fri, 23 Jun 2006 13:09:00 -0000 [thread overview]
Message-ID: <449BD7F5.5090604@st.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 799 bytes --]
When 'set debug expression 1' is used the debug code prints the full
contents of the expression 'elts' as a hex/ASCII dump. Unfortunately
this is a union so parts of it are potentially uninitialised.
This is not normally a problem (although displaying random data doesn't
sound like a good idea to me - especially for autotester etc.), but when
run under valgrind it causes a lot of output which hides the real problems.
The attached patch initialises the union before using it to ensure that
the whole thing is initialised. I suppose that it is not necessary to
initialise it in all the cases I have covered - the data fills the union
anyway, but it is safer this way and I imagine the compiler will do the
right thing in any case.
Tested with no regressions.
Andrew Stubbs
:ADDPATCH parse.c:
[-- Attachment #2: debug-expression.patch --]
[-- Type: text/plain, Size: 1693 bytes --]
2006-06-23 Andrew Stubbs <andrew.stubbs@st.com>
* parse.c (write_exp_elt_opcode, write_exp_elt_sym, write_exp_elt_block
write_exp_elt_longcst, write_exp_elt_dblcst, write_exp_elt_type,
write_exp_elt_intern): Zero initialize tmp.
Index: src/gdb/parse.c
===================================================================
--- src.orig/gdb/parse.c 2006-06-23 11:21:56.000000000 +0100
+++ src/gdb/parse.c 2006-06-23 11:29:35.000000000 +0100
@@ -191,6 +191,7 @@ void
write_exp_elt_opcode (enum exp_opcode expelt)
{
union exp_element tmp;
+ memset (&tmp, 0, sizeof (union exp_element));
tmp.opcode = expelt;
@@ -201,6 +202,7 @@ void
write_exp_elt_sym (struct symbol *expelt)
{
union exp_element tmp;
+ memset (&tmp, 0, sizeof (union exp_element));
tmp.symbol = expelt;
@@ -211,6 +213,7 @@ void
write_exp_elt_block (struct block *b)
{
union exp_element tmp;
+ memset (&tmp, 0, sizeof (union exp_element));
tmp.block = b;
write_exp_elt (tmp);
}
@@ -219,6 +222,7 @@ void
write_exp_elt_longcst (LONGEST expelt)
{
union exp_element tmp;
+ memset (&tmp, 0, sizeof (union exp_element));
tmp.longconst = expelt;
@@ -229,6 +233,7 @@ void
write_exp_elt_dblcst (DOUBLEST expelt)
{
union exp_element tmp;
+ memset (&tmp, 0, sizeof (union exp_element));
tmp.doubleconst = expelt;
@@ -239,6 +244,7 @@ void
write_exp_elt_type (struct type *expelt)
{
union exp_element tmp;
+ memset (&tmp, 0, sizeof (union exp_element));
tmp.type = expelt;
@@ -249,6 +255,7 @@ void
write_exp_elt_intern (struct internalvar *expelt)
{
union exp_element tmp;
+ memset (&tmp, 0, sizeof (union exp_element));
tmp.internalvar = expelt;
next reply other threads:[~2006-06-23 13:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-23 13:09 Andrew STUBBS [this message]
2006-07-06 13:34 ` Daniel Jacobowitz
2006-07-06 14:07 ` Andrew STUBBS
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=449BD7F5.5090604@st.com \
--to=andrew.stubbs@st.com \
--cc=gdb-patches@sourceware.org \
/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