From: "Agovic, Sanimir" <sanimir.agovic@intel.com>
To: 'Tom Tromey' <tromey@redhat.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: RE: [PATCH 06/10] vla: update type from newly created value
Date: Wed, 20 Nov 2013 07:56:00 -0000 [thread overview]
Message-ID: <0377C58828D86C4588AEEC42FC3B85A7176B7EEA@IRSMSX105.ger.corp.intel.com> (raw)
In-Reply-To: <87wqkkt03g.fsf@fleche.redhat.com>
> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com]
> Sent: Thursday, November 07, 2013 09:43 PM
> To: Agovic, Sanimir
> Cc: gdb-patches@sourceware.org
> Subject: Re: [PATCH 06/10] vla: update type from newly created value
>
> >>>>> "Sanimir" == Sanimir Agovic <sanimir.agovic@intel.com> writes:
>
> Sanimir> Constructing a value based on a type and address might change
> Sanimir> the type of the newly constructed value. Thus re-fetch type via
> Sanimir> value_type to ensure we have the correct type at hand.
>
> Sanimir> 2013-10-18 Sanimir Agovic <sanimir.agovic@intel.com>
> Sanimir> Keven Boell <keven.boell@intel.com>
>
> Sanimir> * valops.c (value_ind): Re-fetch type from value.
> Sanimir> * value.c (coerce_ref): Re-fetch type from value.
>
> This is fine by itself; however, I wonder whether there are other calls
> that require fixing. Did you check through the rest of the code?
>
My approach to find similar occurrences:
1) Grep sources for value_at / value_at_lazy / value_from_contents_and_address
2) Follow control flow within a function, if the type passed to the above
constructors is used after constructing a value I re-fetched the type.
Running the testsuite before/after this patch series showed no regressions.
I used Jans diffgdb. gjc, gcc/++, pascal, and ada was used on Fedora20.
I run into some ada fails with and without c99 patches. Not sure if this
is known or expected:
FAIL: gdb.ada/interface.exp: print s
FAIL: gdb.ada/iwide.exp: print My_Drawable
FAIL: gdb.ada/iwide.exp: print s_access.all
FAIL: gdb.ada/iwide.exp: print sp_access.all
FAIL: gdb.ada/iwide.exp: print d_access.all
FAIL: gdb.ada/iwide.exp: print dp_access.all
FAIL: gdb.ada/ptype_tagged_param.exp: ptype s
FAIL: gdb.ada/tagged.exp: ptype obj
FAIL: gdb.ada/tagged.exp: print obj
Below you will find all hits. Let me know if it is OK.
diff --git a/gdb/ada-lang.c b/gdb/ada-lang.c
index 9ff3ab9..26d0c24 100644
--- a/gdb/ada-lang.c
+++ b/gdb/ada-lang.c
@@ -2299,6 +2299,7 @@ ada_value_primitive_packed_val (struct value *obj, const gdb_byte *valaddr,
else if (VALUE_LVAL (obj) == lval_memory && value_lazy (obj))
{
v = value_at (type, value_address (obj));
+ type = value_type (v);
bytes = (unsigned char *) alloca (len);
read_memory (value_address (v) + offset, bytes, len);
}
@@ -7656,6 +7657,7 @@ ada_template_to_fixed_record_type_1 (struct type *type,
size first before creating the value. */
check_size (rtype);
dval = value_from_contents_and_address (rtype, valaddr, address);
+ rtype = value_type (dval);
}
else
dval = dval0;
@@ -7758,7 +7760,10 @@ ada_template_to_fixed_record_type_1 (struct type *type,
off = TYPE_FIELD_BITPOS (rtype, variant_field);
if (dval0 == NULL)
- dval = value_from_contents_and_address (rtype, valaddr, address);
+ {
+ dval = value_from_contents_and_address (rtype, valaddr, address);
+ rtype = value_type (dval);
+ }
else
dval = dval0;
@@ -7899,7 +7904,10 @@ to_record_with_fixed_variant_part (struct type *type, const gdb_byte *valaddr,
return type;
if (dval0 == NULL)
- dval = value_from_contents_and_address (type, valaddr, address);
+ {
+ dval = value_from_contents_and_address (type, valaddr, address);
+ type = value_type (dval);
+ }
else
dval = dval0;
@@ -8197,6 +8205,8 @@ ada_to_fixed_type_1 (struct type *type, const gdb_byte *valaddr,
value_from_contents_and_address (fixed_record_type,
valaddr,
address);
+
+ fixed_record_type = value_type (obj);
if (real_type != NULL)
return to_fixed_record_type
(real_type, NULL,
diff --git a/gdb/cp-valprint.c b/gdb/cp-valprint.c
index 1d7147c..72c8d41 100644
--- a/gdb/cp-valprint.c
+++ b/gdb/cp-valprint.c
@@ -446,6 +446,7 @@ cp_print_value_fields_rtti (struct type *type,
/* Ugh, we have to convert back to a value here. */
value = value_from_contents_and_address (type, valaddr + offset,
address + offset);
+ type = value_type (value);
/* We don't actually care about most of the result here -- just
the type. We already have the correct offset, due to how
val_print was initially called. */
@@ -548,6 +549,7 @@ cp_print_value (struct type *type, struct type *real_type,
base_val = value_from_contents_and_address (baseclass,
buf,
address + boffset);
+ baseclass = value_type (base_val);
thisoffset = 0;
boffset = 0;
thistype = baseclass;
diff --git a/gdb/d-valprint.c b/gdb/d-valprint.c
index 6e9c28d..cca629a 100644
--- a/gdb/d-valprint.c
+++ b/gdb/d-valprint.c
@@ -59,6 +59,7 @@ dynamic_array_type (struct type *type, const gdb_byte *valaddr,
true_type = lookup_array_range_type (true_type, 0, length - 1);
ival = value_at (true_type, addr);
+ true_type = value_type (ival);
d_val_print (true_type,
value_contents_for_printing (ival),
diff --git a/gdb/jv-valprint.c b/gdb/jv-valprint.c
index cb89a85..27901a3 100644
--- a/gdb/jv-valprint.c
+++ b/gdb/jv-valprint.c
@@ -65,6 +65,7 @@ java_value_print (struct value *val, struct ui_file *stream,
type = lookup_pointer_type (type);
val = value_at (type, address);
+ type = value_type (val);
}
}
diff --git a/gdb/valops.c b/gdb/valops.c
index 6706d9f..b539610 100644
--- a/gdb/valops.c
+++ b/gdb/valops.c
@@ -268,6 +268,7 @@ value_cast_structs (struct type *type, struct value *v2)
{
v = value_full_object (v2, real_type, full, top, using_enc);
v = value_at_lazy (real_type, value_address (v));
+ real_type = value_type (v);
/* We might be trying to cast to the outermost enclosing
type, in which case search_struct_field won't work. */
@@ -803,6 +804,7 @@ value_dynamic_cast (struct type *type, struct value *arg)
return value_at_lazy (type, addr);
tem = value_at (type, addr);
+ type = value_type (tem);
/* The first dynamic check specified in 5.2.7. */
if (is_public_ancestor (arg_type, TYPE_TARGET_TYPE (resolved_type)))
-Sanimir
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
next prev parent reply other threads:[~2013-11-20 7:54 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-21 14:40 C99 variable length array support Sanimir Agovic
2013-10-21 14:40 ` [PATCH 10/10] test: add mi vla test Sanimir Agovic
2013-11-07 21:31 ` Tom Tromey
2013-10-21 14:40 ` [PATCH 09/10] test: basic c99 vla tests Sanimir Agovic
2013-11-07 21:23 ` Tom Tromey
2013-10-21 14:40 ` [PATCH 04/10] vla: enable sizeof operator for indirection Sanimir Agovic
2013-11-07 19:57 ` Tom Tromey
2013-10-21 14:40 ` [PATCH 01/10] vla: introduce new bound type abstraction adapt uses Sanimir Agovic
2013-11-07 19:00 ` Tom Tromey
2013-11-18 11:15 ` Agovic, Sanimir
2013-10-21 14:40 ` [PATCH 08/10] test: multi-dimensional c99 vla Sanimir Agovic
2013-11-07 21:19 ` Tom Tromey
2013-10-21 14:40 ` [PATCH 06/10] vla: update type from newly created value Sanimir Agovic
2013-11-07 20:56 ` Tom Tromey
2013-11-20 7:56 ` Agovic, Sanimir [this message]
2013-11-20 11:02 ` Pedro Alves
2013-11-20 13:08 ` Agovic, Sanimir
2013-11-21 18:50 ` Pedro Alves
2013-11-23 19:27 ` Doug Evans
2013-10-21 14:40 ` [PATCH 07/10] test: evaluate pointers to C99 vla correctly Sanimir Agovic
2013-11-07 20:57 ` Tom Tromey
2013-11-08 6:37 ` Tom Tromey
2013-11-07 21:14 ` Tom Tromey
2013-10-21 14:40 ` [PATCH 03/10] vla: enable sizeof operator to work with variable length arrays Sanimir Agovic
2013-11-07 19:10 ` Tom Tromey
2013-10-21 14:40 ` [PATCH 05/10] vla: allow side effects for sizeof argument Sanimir Agovic
2013-10-24 19:55 ` Tom Tromey
2013-10-25 8:13 ` Agovic, Sanimir
2013-10-28 21:00 ` Tom Tromey
2013-11-18 9:37 ` Agovic, Sanimir
2013-11-18 15:56 ` Tom Tromey
2013-11-20 12:18 ` Agovic, Sanimir
2013-11-19 17:08 ` Pedro Alves
2013-11-20 12:47 ` Agovic, Sanimir
2013-11-20 13:24 ` Pedro Alves
2013-10-21 14:40 ` [PATCH 02/10] type: add c99 variable length array support Sanimir Agovic
2013-11-07 19:02 ` Tom Tromey
2013-11-19 15:31 ` Agovic, Sanimir
2013-11-22 20:00 ` Tom Tromey
2013-11-27 17:08 ` Agovic, Sanimir
[not found] ` <0377C58828D86C4588AEEC42FC3B85A7176BC3DE@IRSMSX105.ger.corp.intel.com>
2013-11-27 17:15 ` Agovic, Sanimir
2013-11-07 19:10 ` Tom Tromey
2013-11-21 18:52 ` C99 " Pedro Alves
2013-11-21 19:01 ` Pedro Alves
2013-11-21 19:10 ` Pedro Alves
2013-11-22 10:53 ` Agovic, Sanimir
2013-11-22 12:35 ` Pedro Alves
2013-11-22 17:06 ` Agovic, Sanimir
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=0377C58828D86C4588AEEC42FC3B85A7176B7EEA@IRSMSX105.ger.corp.intel.com \
--to=sanimir.agovic@intel.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).