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

[Andrew Cagney <cagney@gnu.org>]

>>>> > 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.
> 
> 
> First point is understood, but about writing to register --
> 
> How else can this be handled? i.e. where else in the code path of
> call_function_by_hand () will I be able to get ahold of the function
> descriptor and set the gp?

Unfortunatly not here -> it's called with an exec-target for which 
writing register values is meaningless.  It's also ment to have no side 
effects :-/

 > Unfortunately the func_addr that is passed
> into push_dummy_call is already the canonicalized function address,
> so i cannot do this as part of e.g. find_global_pointer.

For PPC64 I used ABI knowledge to do a code address -> descriptor 
address reverse lookup.  Can you do something similar?

You've come across one of GDB's weak points - GDB currently isn't the 
best when it comes to juggling function descriptors and code addresses. 
  Function pointer parameters, for instance, have a similar problem - 
PPC64 push-dummy-call finds itself pushing code-address and not the 
descriptor address and hence messes them up :-(

Anyway, a thing-to-do-one day is to pass the function's ``value'' 
(descriptor and type) to push-dummy-call (there has been talk of doing 
this before).  Another is to clean up what's passed as the parameter 
list -> again descriptors.

Andrew