On Tue, 21 Jan 2014, Matthew Fortune wrote: > The MSA patch as submitted is another variation of O32 ABI which could > be described as O32+FP64+MSA(+nan2008) and would be link incompatible > with both O32 and O32+FP64(+/-nan2008). The same of course applies to > N32/N64 being link incompatible with N32/N64+FP64. This may make it > difficult to have a small part of an application optimised with MSA but > the rest of the code ignorant of MSA, in your experience do you think > that will be an issue?
In general, unnecessary ABI incompatibility is to be discouraged. This means (I'm talking about all architectures, not just MIPS): * Use dynamic stack realignment rather than increasing the alignment assumed by callees. * New registers should be call-clobbered, so setjmp/longjmp (and *context functions) don't need to save and preserve them. * Do not change layout or alignment of existing types. * If your architecture defines that some ISA feature can only coexist with other ISA features (for example, that it can only coexist with hardware floating point, or only with 64-bit support) then that may reduce the number of ABI variants that need to be defined. * If you want to pass vector arguments (or return values) in new registers, without affecting the ABI for any non-vector argument or return type, we're a bit more relaxed on that - but if this affects GNU C generic vectors rather than just architecture-specific vector types there should, at least, be a -Wpsabi warning about the ABI change implied by enabling the vector instructions. Alternatively, enable such argument passing only with an ABI option e.g. -mmsa-abi, rather than with the same option that enables the new instructions. In either case, you need to make sure the dynamic linker is built with the new instructions disabled, to avoid it clobbering the new registers (just as it generally needs special handling for call-clobbered registers involved in argument passing). * In any case, write an ABI document at an early stage that documents how the new registers interact with the ABI. If you do conclude that you need a new, incompatible ABI, then the following also apply - see the NaN2008 changes for recent MIPS examples: * Ensure the static linker gives errors for linking incompatible objects (whether with GNU object attributes, ELF header bits, or some other mechanism). * For glibc, define new dynamic linker names (see recent discussion on the glibc lists) and ensure the corresponding specs in GCC pass the right arguments to -dynamic-linker. * Ensure that glibc can tell executables / shared libraries for the different ABIs apart by examining the ELF header, ensure elf_machine_matches_host checks compatibility, and ensure ldconfig handles the different kinds of executables / shared libraries (_DL_CACHE_DEFAULT_ID, readelflib.c:process_elf_file, etc.). -- Joseph S. Myers jos...@codesourcery.com
