Re: [patch/rfc/hppa] handle setting gp for calling shlib functions

[Andrew Cagney <cagney at gnu dot org>]

> +#define FIND_GLOBAL_POINTER \
> +  (gdbarch_tdep (current_gdbarch)->find_global_pointer)
> +
Just not this (macro's are bad m'kay :-).  The code should instead do 
something like:

	struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
	...
	... = tdep->find_global_pointer (...);

You'll find most architecture functions have that near the start.

The function also needs to add gdbarch|tdep|frame parameters and then 
use them instead of relying on globals such as current_gdbarch (I need 
to deprecate that)(1).

>  static CORE_ADDR
> +hppa32_convert_from_func_ptr_addr (struct gdbarch *gdbarch,
> +				   CORE_ADDR addr,
> +				   struct target_ops *targ)
> +{
> +  if (addr & 2)
> +    {
> +      ULONGEST gp;
> +
> +      addr &= ~3;
> +
> +      gp = read_memory_unsigned_integer (addr + 4, 4);
> +      write_register (19, gp);
> +      addr = read_memory_unsigned_integer (addr, 4);
> +    }
> +
> +  return addr;
> +}
> +
> +static CORE_ADDR

This should be using TARG methods read memory(2), and should not be 
writing GP to register 19.

Andrew

PS: The direction is strongly away from global state.  Already GDB has 
instances where two targets and/or architectures exist simultaneously:
(1) When handling 32 on 64-bit debugging (e.g., i386 on amd64) both 
architectures are active.
(2) Computing the entry point address, both the executable 
(un-relocated) and process targets are active.