enable n32 and n64, and move o32 into mips/mips32

[Alexandre Oliva]

On Mar 20, 2003, Alexandre Oliva <aoliva@redhat.com> wrote:

> I have another idea that I'm exploring right now.  I'll let you know
> when I've got it working.

Seems to have worked, indeed.  It can now pick the ABI choice from
either the tuple (say mips64-linux-gnuabin64) or from the compiler
flags (-mabi=64 in CC, CFLAGS or CPPFLAGS).  The detected ABI is added
to CPPFLAGS such that it's used in configure tests, but CPPFLAGS
doesn't make it to config.make (and it doesn't seem to be used
uniformly anyway), so I explicitly add the chosen ABI to CC in the
sysdeps Makefile.  This is working beautifully, it's limited to
mips64-specific code in configure.in, and it's robust to conflicting
specifications.

I went ahead and made it bi-endian as well.  Ok to install, if it
doesn't regress o32?  (I intend to get at least o32 to a point in
which it builds and works again before putting this in, but it would
be nice to get approval first, such that it doesn't break again
between my fixing it and my getting approval.).  


This can't go in before the following patch either:

	* sysdeps/mips/elf/ldsodefs.h: Add mips-specific elf64 relocation
	data structures and macros.  Protect from multiple inclusion.

and I'd rather not put it in before :

	* sysdeps/unix/sysv/linux/mips/mips64/n32/dl-librecon.h: New file.
	* sysdeps/unix/sysv/linux/mips/mips64/n64/dl-librecon.h: New file.
	* elf/rtld.c (process_envvars): Handle
	EXTRA_LD_PROCESS_ENVVARS_DECLS, EXTRA_LD_LEN14_ENVVARS and
	EXTRA_LD_AFTER_PROCESS_ENVVARS.

These are the only pending patches from my local 2.3.1-based tree for
the mips64-linux-gnu port to be complete.  I'm sure there's at least
one major issue that has to be addressed before it works in mainline
again: the recent atomicity->atomic patches (*), and probably
INLINE_SYSCALLS for n32 and n64.

(*) I find it odd that Uli uses global changes as an argument against
accepting changes that are mips-specific, given that he doesn't care
to make changes to mips-specific code anyway, and he doesn't even
apologize for leaving it out, probably breaking the port.  I take it
that this argument was as much of an attempt to obscure his prejudice
against mips with an argument that would be valid only if he actually
tried to keep mips working when making global changes.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: mips64-enable-n32-n64.patch
Type: text/x-patch
Size: 27721 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20030322/b54411cf/attachment.bin>
-------------- next part --------------

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer