Completing toplevel libgcc move (Was: Re: [SPARC] Hookize PRINT_OPERAND, PRINT_OPERAND_ADDRESS and PRINT_OPERAND_PUNCT_VALID_P)

[Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>]

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

> On Wed, 4 May 2011, Rainer Orth wrote:
>
>> Your expansion of the wiki page on toplevel libgcc migration is
>> certainly welcome: I hadn't seen before that *-unwind.h files and
>> related macros can be moved over as well.
>
> I've no idea whether they can be moved *at present*, but certainly the 
> eventual aim should be to move them.
>
> Before more macros are moved to files in libgcc/config I'd really rather 
> the libgcc headers go in a separate libgcc_tm_file or similar, not 
> included on the host and with the moved macros poisoned in the host 
> system.h, to avoid the situation listed on that page of "RENAME_LIBRARY 
> (in gcc/config/arm/symbian.h, otherwise moved to libgcc headers)" where a 
> macro is only partly migrated to the libgcc headers but this partial state 
> isn't obvious.  This has the advantage of avoiding the 
> ../../libgcc/config/ kludge in tm_file as well.

But doesn't this mean that e.g. MD_UNWIND_SUPPORT can only be moved to
libgcc/config for all targets together?  How can you poison the macro
when a single target using it is left behind in gcc/config?

To actually test such a move, one had to setup complete
cross-environments for every affected target, which is way beyond what I
have the time and inclination to do.  This would mean that even targets
where the toplevel libgcc move could be completed and the maintainers
are motivated to do so are stalled until all other related ones are
done.  Doesn't seem highly desirable to me.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University