Re: Fix build with compiler defining __i686 (bug 411)

[Roland McGrath <roland at hack dot frob dot com>]

I think it makes most sense to do this piecemeal and in a different order.

First, clean up everything to use SETUP_PIC_REG{,_STR} uniformly.
Second, clean up everything to use GET_PC_THUNK{,_STR} uniformly, but
give that a trivial definition.
Third, conditionalize GET_PC_THUNK{,_STR} for GCC>=4.7.

Those steps seem thoroughly noncontroversial.

Then perhaps it's time to seriously consider the initfini situation
before anything that necessitates really strange kludges inside it.

Finally, actually deal with __i686.

I may have omitted some details, but you get the idea.  It orders the
least controversial issues first, so we can get those committed before
hashing out further.  It avoids churn of changing the same code twice.

Is there anything that can be done to optimize the case of
libc_nonshared.a compiled with GCC >= 4.7 and linked with code
compiled with GCC < 4.7, or vice versa?  Off hand I don't think there
is any clever way to avoid having two thunks, each in a linkonce
section of each name, but it's worth a little thought.  Even if there
is only a way to make one of them completely dead with all calls going
to the other, that might be worthwhile (not that I've quite thought of
one).


Thanks,
Roland