Re: regcache (Re: GDB respin)

[Andrew Cagney <ac131313 at redhat dot com>]

> diff -u -p -r1.33 -r1.34
> --- gdb/x86-64-tdep.c   26 Oct 2002 10:37:45 -0000      1.33
> +++ gdb/x86-64-tdep.c   26 Oct 2002 16:56:34 -0000      1.34
> @@ -925,11 +925,35 @@ x86_64_init_abi (struct gdbarch_info inf
> +  set_gdbarch_long_double_bit (gdbarch, 128);
> +  set_gdbarch_ps_regnum (gdbarch, 17); /* %eflags */
> +  set_gdbarch_stab_reg_to_regnum (gdbarch, x86_64_dwarf2_reg_to_regnum);
> +  set_gdbarch_dwarf_reg_to_regnum (gdbarch, x86_64_dwarf2_reg_to_regnum);
> +  set_gdbarch_extract_return_value (gdbarch, NULL);
> +  set_gdbarch_store_return_value (gdbarch, NULL);
> +  set_gdbarch_extract_struct_value_address (gdbarch, NULL);
>
> If I comment out last three lines (those return_value related), the testsuite performs much better. But all the other lines seem have some influence on the results.
Hmm, at least extract_return_value shouldn't be set to NULL.  It should 
be doing:
	extract-return-value()
	-> legacy-extract-return-value()
	-> deprecated-extract-return-value()
	-> x86-64-extract-return-value
So I'd at least remove the setting of that one.  Since it is trying to 
restore the default, try setting it to legacy_...().  Same goes for 
store_return_value.  I think extract_struct_value_address is puzzling 
but ok.

> I'm about to convert x86-64 target to use regcache, but am not sure what must be done for it. Could someone please briefly explain me what is regcache all about and what must be changed in order to have the target regcache-compilant?
Where previously the code wrote (directly or implicitly) to a global 
buffer, it how is given an explicit object (the regcache).

You can use any *cooked*{read,write}* function you want in regcache.h. 
Typically the transformation is very direct: write_register() -> 
regcache_cooked_write().

> As I was looking to the sources I believe, that only x86_64_store_return_value() and x86_64_extract_return_value() must be modified. Am I right or not?
Per above, yes, I think this is correct.  Thanks!

Andrew