Mark Kettenis kettenis@chello.nl
Mon Nov 10 21:49:00 GMT 2003

   Date: Sun, 09 Nov 2003 15:38:18 -0500
   From: Andrew Cagney <cagney@gnu.org>

   > 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.

gdbarch has-a shared library architecture.  Yes, we defenitely need
that.  I have some thoughts on it.  But I want to finish SPARC and the
corefile stuff first...

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

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

   Then the macro can be deprecated.

I'll get rid of the SKIP_SOLIB_RESOLVER macro completely, but
unfortunately I won't have time to do this before friday.


More information about the Gdb-patches mailing list