Steve Ellcey <[email protected]> writes:
> On Fri, 2012-06-22 at 10:24 +0100, Richard Sandiford wrote:
>
>> If you use a different target name, the specs for that target can
>> enforce whatever triplet-specific defaults you want. See the
>> DRIVER_SELF_SPECS in vr.h for a particularly involved example.
>> (Yours shouldn't need to be as bad!)
>
> I think that using DRIVER_SELF_SPECS would still require me to figure
> out exactly what architectures support -msynci and which don't in order
> to pass the right thing.
Not if you use MIPS_ISA_LEVEL_SPEC. I think you'd want that anyway,
in order to pick the right multilib. E.g. MIPS_ISA_LEVEL_SPEC is
the thing that would make -march=4kc pick the mips32 rather than
mips32r2 multilibs.
Since you have soft-float multilibs, you'd probably also want
MIPS_ARCH_FLOAT_SPEC.
Or to put it another way, MIPS_ISA_LEVEL_SPEC and MIPS_ARCH_FLOAT_SPEC
make the multilib options explicit on the command line. You can then
use that information to add whatever options you want to be the default
for a given multilib.
> What I liked about -msynci-if-supported is that it means there is only
> one check to determine if synci is supported, the one in mips.h, and
> so I don't have to worry about two different tests not being
> consistent.
It opens up a can of worms though. I think these --with-* options
should be consistent. If we say that --with-synci should be overridden
by anything that is incompatible with it, then the same should apply
to --with-abi, --with-arch, etc. (And the same should be true for
things like --with-mode on ARM.)
E.g. if you pass -mgp64 to a compiler that was configured with --with-arch,
then presumably we should ignore that --with-arch if it specifies a 32-bit
architecture, but continue to honour it if it specifies a 64-bit
architecture. (I realise we have --with-arch-32 and --with-arch-64, but
the principle holds regardless.) So say you have a target that is usually
mips64 by default, but that has 32-bit multilibs. If you configure with
--with-arch=mips32r2 --with-synci, then pass -mgp64, what should happen?
I assume we'd revert back to the default of mips64 and then (after your
change) silently drop the -msynci too. And that feels like too much
guesswork on our part. Maybe the user really wanted mips64r2.
That's just one example. The same thing would apply to --with-abi.
The relationships between these options are so complicated that
I think the user interface should be as simple as possible.
And IMO, that means that if the user explicitly configures with
--with-synci, then they should use -mno-synci if they want to
reverse that decision.
Packagers who want to provide both -msynci and -mno-synci multilibs
(with mips32 being one possible form of the latter) should IMO define
an appropriate configuration that doesn't rely on --with-synci.
>> If so, we need to define what the OS library directories
>> are for -EB vs -EL, -mhard-float vs. -msoft-float, etc.
>> Are you planning to extend the IRIX lib/lib32/lib64 system,
>> or use the Debian/Ubuntu multiarch?
>>
>> Richard
>
> I was looking at lib/lib32/lib64. Here is the full t-mti file I was
> trying to build with the latest sources:
>
> MULTILIB_OPTIONS = EL/EB msoft-float mips32
> MULTILIB_DIRNAMES = el eb soft-float mips32
> MULTILIB_MATCHES := EL=mel EB=meb
> EXTRA_MULTILIB_PARTS = crtbegin.o crtend.o crtbeginS.o crtendS.o crtbeginT.o
>
> and I also have a mti.h header file with:
>
> #define MULTILIB_DEFAULTS { "EB" }
> #define SYSROOT_SUFFIX_SPEC \
> "%{mel|EL:/el}%{msoft-float:/soft-float}%{mips32:/mips32}"
Ah, OK, I get it now. Thanks.
Richard
