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

[Andrew Cagney <cagney at gnu dot org>]

> > > 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 mean look through a opd section? unfortunately there isn't such a
> thing for the 32-bit abi. it's there in hppa64. 

Anything.

For pa64, given "<symname>", the descriptor is at ".<symname>" so the 
operation is pretty easy.

> for hppa32, the plabel likely resides in the got/plt, and i don't think
> we can easily find it there.
>
>
> > > 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.
>
>
> well, i can already do this, by *not* implementing the conversion
> function. However, when the actual call is made, we need to do the
> conversion.
>
> how about adding a new gdbarch method breakpoint_from_func_ptr 
> and potentially not calling convert_from_func_ptr_address() from
> call_function_by_hand()? other than ia64, ppc64 and hppa, how many
> function-descriptor archs do we have?

(also xstormy16 at least)

The function/variable is (well was, it appears to have fallen off the 
radar for the moment) also wanted for a second reason.  When it comes to 
implementing ABI variants the full function type info is needed.  Hence, 
a ``struct value'' function descriptor (or descriptor pointer / type) 
are going to eventually be needed anyway.  Hence, I think an updated 
push-dummy-call with the new parameter would be better.

Andrew