[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Patches] The state of the e500 EGLIBC port
- To: <patches@xxxxxxxxxx>
- Subject: [Patches] The state of the e500 EGLIBC port
- From: "Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>
- Date: Tue, 2 Jul 2013 14:52:07 +0000
I tried building the e500 EGLIBC port to check its state for the 2.18
release (now glibc is about to freeze for 2.18, so hopefully release later
this month). Build failures indicated that no-one has been building the
e500 port from trunk for several months.
The apparent lack of interest in the e500 port does leave me wondering if
it's another feature that should be deprecated, like the proposal to
deprecate option groups. But to the extent that there may still be users
for this port, how much do those users care about binary compatibility
with past versions?
I'm tending to the view that there are some ABI mistakes in past decisions
made for this port, including (a) trying to be compatible with the ABI
from Aldy's old spe add-on for glibc 2.3, (b) not having exactly the same
ABI for e500v1 and e500v2, (c) not having the ABI the same as for the
ordinary soft-float powerpc build of glibc (the function-calling ABI is
the same, but not all the symbol versions or <fenv.h> constants), (d)
including the SPE PIM string-to-fixed-point functions in libc rather than
keeping them in a separate library as they were in Aldy's add-on. So if
the port is to be merged into glibc instead of being deprecated (and I
don't consider keeping it long-term as a difference between glibc and
EGLIBC to be a separate option), it would be tempting to fix these
mistakes and make the ABI the same as for soft-float powerpc (with the SPE
PIM functions again coming from a separate add-on).
--
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx
_______________________________________________
Patches mailing list
Patches@xxxxxxxxxx
http://eglibc.org/cgi-bin/mailman/listinfo/patches