> > And as you imply, o32+fp64 is already an established ABI so I think we > > have to support the current form alongside any new one. I agree with > > Joseph that it'd be better to realign the stack dynamically instead. > > This is what x86 does, so it's well tested within gcc. > > With glibc, o32+fp64 is not established - the glibc patch submitted in > November needs more work as I noted in my review, likely to include > dynamic linker names distinct from those used for o32+fp32. So it would be > possible to declare that only a new form is supported with glibc (more > generally, with the Linux kernel, given the lack of current kernel support for > o32+fp64 stated in the glibc discussion), with appropriate configure checks > preventing building glibc with an old-ABI o32+fp64 compiler (and ideally a > #error in some glibc header disallowing building programs with an old-ABI > o32+fp64 compiler).
True, but it doesn't seem wise to have the 'same' ABI work differently between linux and bare metal. Code portability from linux to bare metal (and vice-versa) can be important and whilst code could be written taking the biggest stack alignment into consideration to solve such a problem it still feels wrong to have them work differently. > > -- > Joseph S. Myers > jos...@codesourcery.com
