Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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;


             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