RFA: Fix other/44566

[Joern Rennecke]

Quoting "Joseph S. Myers" <joseph@codesourcery.com>:

> On Sun, 27 Jun 2010, Joern Rennecke wrote:
>> As my work shows, having the hooks coded in the individual targets is not
>> required - using the existing macros to provide hooks works just fine.
>
> It is fragile, because you need a way to ensure that no patch causes a use
> of a macro to be introduced in a file built once-only;

We can fix that: we can poison the macro for these files.  Or to  
express it more robustly: poison them for all files that don't need  
access to this
class of target macros.  I.e. the compiler backend rtl files / targethooks.c
are the only ones to see compiler backend macros, the gcc driver hook file
is the only one to see the driver macros etc.

> Furthermore, one long-term
> aim of modularization is to be able to build front ends and back ends as
> plug-ins separately from the core compiler, which certainly requires
> completing the hook conversion rather than relying on building parts of
> the compiler twice.

No, it doesn't.  I would be a matter of basically packaging up what gets
build in an extra target directory as a plugin, and allow this to be inserted
in a target vector array that either is dynamically allocated, or has free
slots available.  (The latter needs less indirections, so a few dozen wasted
bytes and a limit on the number of simultanously plugged-in backends might
be a price worth paying.)