aboutsummaryrefslogtreecommitdiff
path: root/gdb/c-lang.c
diff options
context:
space:
mode:
authorTom Tromey <tromey@adacore.com>2019-04-25 12:14:58 -0600
committerTom Tromey <tromey@adacore.com>2019-05-08 10:20:06 -0600
commit80e55b132940813fa454da2592a31db6c8af85f1 (patch)
treeebb1b1c183fa1bcec144be4479fd601864131352 /gdb/c-lang.c
parent9d3421afbb9f3cfc8e67366ba75ea12ed8f732a3 (diff)
downloadfsf-binutils-gdb-80e55b132940813fa454da2592a31db6c8af85f1.zip
fsf-binutils-gdb-80e55b132940813fa454da2592a31db6c8af85f1.tar.gz
fsf-binutils-gdb-80e55b132940813fa454da2592a31db6c8af85f1.tar.bz2
Correctly handle non-C-style arrays in c_get_string
A user here noticed that the Python Value.string method did not work for Ada arrays. I tracked this down to an oddity in value_as_address -- namely, it calls coerce_array, but that function will not force array coercion when the language has c_style_arrays=false, as Ada does. This patch fixes the problem by changing c_get_string so that arrays take the "in GDB's memory" branch. The actual patch is somewhat more complicated than you might think, because the caller can request more array elements than the type allows. This is normal when the type is using the C struct hack. Tested on x86-64 Fedora 29. gdb/ChangeLog 2019-05-08 Tom Tromey <tromey@adacore.com> * c-lang.c (c_get_string): Handle non-C-style arrays. gdb/testsuite/ChangeLog 2019-05-08 Tom Tromey <tromey@adacore.com> * gdb.python/py-value.exp (test_value_in_inferior): Add Ada test.
Diffstat (limited to 'gdb/c-lang.c')
-rw-r--r--gdb/c-lang.c31
1 files changed, 27 insertions, 4 deletions
diff --git a/gdb/c-lang.c b/gdb/c-lang.c
index aeffefa..5bb771b 100644
--- a/gdb/c-lang.c
+++ b/gdb/c-lang.c
@@ -279,10 +279,21 @@ c_get_string (struct value *value, gdb::unique_xmalloc_ptr<gdb_byte> *buffer,
/* If the string lives in GDB's memory instead of the inferior's,
then we just need to copy it to BUFFER. Also, since such strings
are arrays with known size, FETCHLIMIT will hold the size of the
- array. */
+ array.
+
+ An array is assumed to live in GDB's memory, so we take this path
+ here.
+
+ However, it's possible for the caller to request more array
+ elements than apparently exist -- this can happen when using the
+ C struct hack. So, only do this if either no length was
+ specified, or the length is within the existing bounds. This
+ avoids running off the end of the value's contents. */
if ((VALUE_LVAL (value) == not_lval
- || VALUE_LVAL (value) == lval_internalvar)
- && fetchlimit != UINT_MAX)
+ || VALUE_LVAL (value) == lval_internalvar
+ || TYPE_CODE (type) == TYPE_CODE_ARRAY)
+ && fetchlimit != UINT_MAX
+ && (*length < 0 || *length <= fetchlimit))
{
int i;
const gdb_byte *contents = value_contents (value);
@@ -306,7 +317,19 @@ c_get_string (struct value *value, gdb::unique_xmalloc_ptr<gdb_byte> *buffer,
}
else
{
- CORE_ADDR addr = value_as_address (value);
+ /* value_as_address does not return an address for an array when
+ c_style_arrays is false, so we handle that specially
+ here. */
+ CORE_ADDR addr;
+ if (TYPE_CODE (type) == TYPE_CODE_ARRAY)
+ {
+ if (VALUE_LVAL (value) != lval_memory)
+ error (_("Attempt to take address of value "
+ "not located in memory."));
+ addr = value_address (value);
+ }
+ else
+ addr = value_as_address (value);
/* Prior to the fix for PR 16196 read_string would ignore fetchlimit
if length > 0. The old "broken" behaviour is the behaviour we want: