From: Tom Tromey <tromey@redhat.com>
To: gdb-patches@sourceware.org
Subject: RFC: fix `gdb -write' case
Date: Fri, 06 May 2011 17:12:00 -0000 [thread overview]
Message-ID: <m3k4e3wy6w.fsf@fleche.redhat.com> (raw)
I'd appreciate comments on this. In the absence of comments I will
check it in. I plan to put it on the 7.3 branch as well.
This comes from:
https://bugzilla.redhat.com/show_bug.cgi?id=696148
The bug is that you cannot change a string in an executable with `gdb
-write'. Jan tracked this down to the wide string change; the bug is
that evaluate_subexp_c did not examine `expect_type', leading to an
attempt to coerce the string to memory.
Built and regtested by our internal buildbot.
Tom
2011-05-06 Tom Tromey <tromey@redhat.com>
* c-lang.c (evaluate_subexp_c): Use expect_type if it is not
NULL.
diff --git a/gdb/c-lang.c b/gdb/c-lang.c
index ad770bf..64c4d79 100644
--- a/gdb/c-lang.c
+++ b/gdb/c-lang.c
@@ -1061,9 +1061,39 @@ evaluate_subexp_c (struct type *expect_type, struct expression *exp,
/* Write the terminating character. */
for (i = 0; i < TYPE_LENGTH (type); ++i)
obstack_1grow (&output, 0);
- result = value_cstring (obstack_base (&output),
- obstack_object_size (&output),
- type);
+
+ if (expect_type && TYPE_CODE (expect_type) == TYPE_CODE_ARRAY)
+ {
+ LONGEST low_bound, high_bound;
+ struct type *element_type
+ = check_typedef (TYPE_TARGET_TYPE (expect_type));
+ int element_size = TYPE_LENGTH (element_type);
+
+ if (TYPE_CODE (element_type) != TYPE_CODE_INT
+ && (TYPE_CODE (element_type) != TYPE_CODE_CHAR))
+ error (_("wrong expected type for string constant"));
+ if (TYPE_LENGTH (element_type) != TYPE_LENGTH (type))
+ error (_("expected type of string constant has wrong "
+ "character width"));
+
+ if (get_discrete_bounds (TYPE_INDEX_TYPE (expect_type),
+ &low_bound, &high_bound) < 0)
+ {
+ low_bound = 0;
+ high_bound = (TYPE_LENGTH (expect_type) / element_size) - 1;
+ }
+ if (obstack_object_size (&output) / TYPE_LENGTH (type)
+ > (high_bound - low_bound + 1))
+ error (_("Too many array elements"));
+
+ result = allocate_value (expect_type);
+ memcpy (value_contents_raw (result), obstack_base (&output),
+ obstack_object_size (&output));
+ }
+ else
+ result = value_cstring (obstack_base (&output),
+ obstack_object_size (&output),
+ type);
}
do_cleanups (cleanup);
return result;
next reply other threads:[~2011-05-06 17:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-06 17:12 Tom Tromey [this message]
2011-05-09 3:11 ` Yao Qi
2011-05-09 14:54 ` Tom Tromey
2011-05-10 2:03 ` Yao Qi
2011-05-10 14:16 ` Tom Tromey
2011-05-11 8:06 ` Jan Kratochvil
2011-05-11 14:38 ` Jan Kratochvil
2011-05-11 19:42 ` Tom Tromey
2011-05-22 18:24 ` Jan Kratochvil
2011-05-23 20:24 ` Tom Tromey
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=m3k4e3wy6w.fsf@fleche.redhat.com \
--to=tromey@redhat.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