This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: [PATCHv3, MIPS] Add support for O32 FPXX and program header based ABI information
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: "'libc-alpha at sourceware dot org'" <libc-alpha at sourceware dot org>, "Moore, Catherine (Catherine_Moore at mentor dot com)" <Catherine_Moore at mentor dot com>, 'Andrew Pinski' <pinskia at gmail dot com>, "Rich Felker (dalias at libc dot org)" <dalias at libc dot org>, Rich Fuhler <Rich dot Fuhler at imgtec dot com>, "'macro at codesourcery dot com'" <macro at codesourcery dot com>
- Date: Tue, 7 Oct 2014 21:06:37 +0000
- Subject: RE: [PATCHv3, MIPS] Add support for O32 FPXX and program header based ABI information
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B0235320F1A039 at LEMAIL01 dot le dot imgtec dot org> <Pine dot LNX dot 4 dot 64 dot 1410022033580 dot 21905 at digraph dot polyomino dot org dot uk>
Joseph S. Myers <joseph@codesourcery.com> writes:
> On Thu, 2 Oct 2014, Matthew Fortune wrote:
>
> > == Mixing old and new executables with post-PT_MIPS_ABIFLAGS dynamic
> linkers ==
> >
> > One caveat appears when mixing old soft-float with new soft-float. Since
> the old
> > soft-float binaries had no dynamic linker visible markings then
> > post-PT_MIPS_ABIFLAGS logic detects these as hard-float. This means that
> mixing
> > old and new soft-float is not possible and will be rejected. Since soft-
> float is
> > not a publicly supported ABI variant for any major MIPS Linux distribution
> it
> > seems reasonable for this to take the hit of needing a re-build.
>
> No, this should work - meaning that the new logic should accept old
> binaries without PT_MIPS_ABIFLAGS as possibly being either hard or soft
> float.
Just checking your opinion here. I'm relaxing the linkage rules for
non-PT_GNU_MIPS binaries such that they can link with SOFT|DOUBLE|FPXX|FP64A
but strictly not FP64. I am on the fence as to whether I should allow SINGLE
as well. Strictly speaking there could be GNU systems with single-float but
I don't think GLIBC supports single-float so it is unlikely that there are any
non-PT_GNU_MIPS binaries out there using single-float. Every special case
costs extra code complexity and test coverage so if it is not important I'd
rather leave it.
What do you think?
Matthew