Re: [PATCH] Multi-arch SKIP_SOLIB_RESOLVER

[Andrew Cagney <cagney@gnu.org>]

>    Date: Sun, 09 Nov 2003 08:38:57 -0500
>    From: Andrew Cagney <cagney@gnu.org>
> 
>    > I'm working on integrating some mostly SPARC-related patches from
>    > David S. Miller.  There were also some general bits in his tree that
>    > I'm going to check in on mainline.  Here's the first.
> 
>    You mean the stuff david posted here?
> 
> Some of it has been posted, some hasn't.  I explicitly asked David
> about the copyright status, and he told me it was all written by
> himself, and that is copyright assignment is still in place.
> 
>    > Committed as obvious (to mainline).
> 
>    It should be "m" or "M", and not "f".
>    You'll also note that I've started deleting still lurking macros so 
>    these conversions are no longer so obvious :-)
> 
> Hmm.  So the "f" conversions are no longer considered obvious?  The
> problem with "m" and "M" is that they no longer define the macro that
> we're replacing.  That means things become a bit more complicated.  Do
> you want me to replace SKIP_SOLIB_RESOLVER with a truly multi-arched
> function?

Yep.  More generally, I'd prefer to see people try to consolidate 
existing methods, or create a new "gdbarch has-a" relationship(1), 
rather than add yet another architecture method.  The architecture 
vector contains so much redundancy that it is depressing.

Any way, for your case, make the default something like:

CORE_ADDR
cannot_skip_solib_resolver (struct gdbarch *gdbarch, CORE_ADDR pc)
{
#ifdef SKIP_SOLIB_RESOLVER
	/* Ok the function's name is a lie.   This is here to prop up old 
architectures and should be deleted.  */
	return SKIP_SOLIB_RESOLVER(...);
#else
  	return 0;
#endif
}

Then the macro can be deprecated.

Andrew

(1) As in gdbarch has-a reggroup, gdbarch has-a unwinder, gdbarch has-a 
regset, ...