[2/3] Set VALUE_VAL before set_value_address

  Since we have a check on VALUE_VAL in set_value_address, we need to
set VALUE_VAL properly before set_value_address.

gdb:

2016-11-21  Yao Qi  <yao.qi@linaro.org>

	* ada-lang.c (ensure_lval): Call set_value_address after setting
	VALUE_LVAL.
	* elfread.c (elf_gnu_ifunc_resolve_addr): Set VALUE_LVAL to
	lval_memory.
	(elf_gnu_ifunc_resolver_return_stop): Likewise.
	* value.c (value_fn_field): Likewise.
	(value_from_contents_and_address_unresolved): Likewise.
	(value_from_contents_and_address): Likewise.
---
 gdb/ada-lang.c | 2 +-
 gdb/elfread.c  | 2 ++
 gdb/value.c    | 5 +++--
 3 files changed, 6 insertions(+), 3 deletions(-)
  

On 11/22/2016 09:48 AM, Yao Qi wrote:
> Since we have a check on VALUE_VAL in set_value_address, we need to
> set VALUE_VAL properly before set_value_address.
>
> gdb:
>
> 2016-11-21  Yao Qi  <yao.qi@linaro.org>
>
> 	* ada-lang.c (ensure_lval): Call set_value_address after setting
> 	VALUE_LVAL.
> 	* elfread.c (elf_gnu_ifunc_resolve_addr): Set VALUE_LVAL to
> 	lval_memory.
> 	(elf_gnu_ifunc_resolver_return_stop): Likewise.
> 	* value.c (value_fn_field): Likewise.
> 	(value_from_contents_and_address_unresolved): Likewise.
> 	(value_from_contents_and_address): Likewise.
> ---
>  gdb/ada-lang.c | 2 +-
>  gdb/elfread.c  | 2 ++
>  gdb/value.c    | 5 +++--
>  3 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/gdb/ada-lang.c b/gdb/ada-lang.c
> index 0647a9b..33591af 100644
> --- a/gdb/ada-lang.c
> +++ b/gdb/ada-lang.c
> @@ -4473,8 +4473,8 @@ ensure_lval (struct value *val)
>        const CORE_ADDR addr =
>          value_as_long (value_allocate_space_in_inferior (len));
>
> -      set_value_address (val, addr);
>        VALUE_LVAL (val) = lval_memory;
> +      set_value_address (val, addr);
>        write_memory (addr, value_contents (val), len);
>      }
>
> diff --git a/gdb/elfread.c b/gdb/elfread.c
> index e49af6d..c6d0fdb 100644
> --- a/gdb/elfread.c
> +++ b/gdb/elfread.c
> @@ -879,6 +879,7 @@ elf_gnu_ifunc_resolve_addr (struct gdbarch *gdbarch, CORE_ADDR pc)
>      name_at_pc = NULL;
>
>    function = allocate_value (func_func_type);
> +  VALUE_LVAL (function) = lval_memory;
>    set_value_address (function, pc);
>
>    /* STT_GNU_IFUNC resolver functions usually receive the HWCAP vector as
> @@ -992,6 +993,7 @@ elf_gnu_ifunc_resolver_return_stop (struct breakpoint *b)
>    gdb_assert (b->loc->next == NULL);
>
>    func_func = allocate_value (func_func_type);
> +  VALUE_LVAL (func_func) = lval_memory;
>    set_value_address (func_func, b->loc->related_address);
>
>    value = allocate_value (value_type);
> diff --git a/gdb/value.c b/gdb/value.c
> index a8ab5db..a093a9a 100644
> --- a/gdb/value.c
> +++ b/gdb/value.c
> @@ -3280,6 +3280,7 @@ value_fn_field (struct value **arg1p, struct fn_field *f,
>      }
>
>    v = allocate_value (ftype);
> +  VALUE_LVAL (v) = lval_memory;
>    if (sym)
>      {
>        set_value_address (v, BLOCK_START (SYMBOL_BLOCK_VALUE (sym)));
> @@ -3666,8 +3667,8 @@ value_from_contents_and_address_unresolved (struct type *type,
>      v = allocate_value_lazy (type);
>    else
>      v = value_from_contents (type, valaddr);
> -  set_value_address (v, address);
>    VALUE_LVAL (v) = lval_memory;
> +  set_value_address (v, address);
>    return v;
>  }
>
> @@ -3692,8 +3693,8 @@ value_from_contents_and_address (struct type *type,
>    if (TYPE_DATA_LOCATION (resolved_type_no_typedef) != NULL
>        && TYPE_DATA_LOCATION_KIND (resolved_type_no_typedef) == PROP_CONST)
>      address = TYPE_DATA_LOCATION_ADDR (resolved_type_no_typedef);
> -  set_value_address (v, address);
>    VALUE_LVAL (v) = lval_memory;
> +  set_value_address (v, address);
>    return v;
>  }
>
>

It sounds like if we go the route of having value_has_address only 
return true for lval_memory, we could get rid of these explicit 
assignments of VALUE_LVAL and make set_value_address set 
VALUE->location.address.

I agree with your initial assessment that only lval_memory should have 
an address. But maybe GDB is using lval_register with other meanings?
  

On 11/22/2016 03:48 PM, Yao Qi wrote:
> Since we have a check on VALUE_VAL in set_value_address, we need to
> set VALUE_VAL properly before set_value_address.

LGTM.

I wonder whether it'd be hard to add a new function that
takes care of the ordering:

  struct value *allocate_memory_value (struct type *type, CORE_ADDR address);

that would allocate a lazy value with lval == lval_memory and
address filled in.  We use that instead throughout.

This would translate more directly to converting struct value to a
class hierarchy down the road, with allocate_memory_value mapping
to a struct memory_value constructor.

Thanks,
Pedro Alves