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

[Andrew Cagney <cagney at gnu dot 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