Re: Patch for pascal-dynamic arrays

[Joost van der Sluis <joost@cnoc.nl>]

[-- Attachment #1: Type: text/plain, Size: 2231 bytes --]

On Mon, 2010-04-12 at 21:51 +0200, Jan Kratochvil wrote:
> On Mon, 12 Apr 2010 13:25:02 +0200, Joost van der Sluis wrote:
> > I have a new patch now that doesn't cause any regressions on my system,
> 
> on Fedora 12 for x86_64-m32 and native i386 (but not for x86_64 native 64bit):
> -PASS: gdb.base/store.exp: var struct 4 u; print old u, expecting {s = \{0, 0, 0, 0}}
> +FAIL: gdb.base/store.exp: var struct 4 u; print old u, expecting {s = \{0, 0, 0, 0}}
> -PASS: gdb.base/store.exp: up struct 4 u; print old u, expecting {s = \{0, 0, 0, 0}}
> +FAIL: gdb.base/store.exp: up struct 4 u; print old u, expecting {s = \{0, 0, 0, 0}}
> 
> Therefore if you have x86_64 native system reproducible by:
> 	cd gdb/testsuite; make site.exp; runtest --target_board unix/-m32 gdb.base/store.exp 

Was hard to find, but attached is a patch. On computed values, the
pointer to the struct with the functions for calculating the actual
value was returned as the data-address. At some point the value struct
got lost and re-created using the value contents and (invalid) address.

> > Any comments, improvements, suggestions?
> 
> I have to admit I do not fell so comfortable with the part:
> 
> @@ -1045,8 +1045,8 @@ get_array_bounds (struct type *type, long *low_bound, long *high_bound)
>  
>    if (TYPE_CODE (index) == TYPE_CODE_RANGE)
>      {
> -      low = TYPE_LOW_BOUND (index);
> -      high = TYPE_HIGH_BOUND (index);
> +      low = value_lower_bound (type);
> +      high = value_upper_bound (type);
>      }
> 
> as it converts the state pre-check_typedef-ed evaluation to a dynamic one.

Hard to get around that. Because all array-elements use the same
type-struct. But they can have different sizes.

> Going to try some alternative adjustment of this part.

Another approach could be to do a full check_typedef before the
code-block above. But then the OBJECT_ADDRESS (as used by check_typedef
to evaluate all dynamic properties) has to be set to the right
(=value_data_address) value. Iirc I've already tried that in an earlier
patch I've send.

But if you have any other suggestions or ideas that's also welcome. I do
not care if the problem is solved as I would do it, as long as we can
find an acceptable solution.

Joost.



[-- Attachment #2: computed_values.diff --]
[-- Type: text/x-patch, Size: 739 bytes --]

diff --git a/gdb/value.c b/gdb/value.c
index cedfc45..bc309d7 100644
--- a/gdb/value.c
+++ b/gdb/value.c
@@ -546,7 +546,8 @@ CORE_ADDR
 value_address (struct value *value)
 {
   if (value->lval == lval_internalvar
-      || value->lval == lval_internalvar_component)
+      || value->lval == lval_internalvar_component
+      || value->lval == lval_computed)
     return 0;
   return value->location.address + value->offset;
 }
@@ -555,7 +556,8 @@ CORE_ADDR
 value_raw_address (struct value *value)
 {
   if (value->lval == lval_internalvar
-      || value->lval == lval_internalvar_component)
+      || value->lval == lval_internalvar_component
+      || value->lval == lval_computed)
     return 0;
   return value->location.address;
 }