This is the mail archive of the
mailing list for the GCC project.
Re: SH Linux: remove big endian multilib
- To: NIIBE Yutaka <gniibe at m17n dot org>
- Subject: Re: SH Linux: remove big endian multilib
- From: "M. R. Brown" <mrbrown at 0xd6 dot org>
- Date: Sat, 4 Aug 2001 11:36:00 -0500
- Cc: Michael Eager <eager at mvista dot com>, Andrew Haley <aph at cambridge dot redhat dot com>, amylaar at redhat dot com, gcc at gcc dot gnu dot org
- References: <email@example.com> <200107270834.f6R8Y5u21170@mule.m17n.org> <3B6B6CE4.2A076E08@mvista.com> <200108040435.f744ZAo18841@mule.m17n.org>
* NIIBE Yutaka <firstname.lastname@example.org> on Sat, Aug 04, 2001:
> > I'm all in favor of removing multilib for sh-linux.
> But this is irrelevant. I agree that sets of "single specified"
> target is good. But I believe that the definition of sh-unknown-linux-gnu
> (sh-linux in short) is supporting multiple targets.
It does. sh-unknown-linux-gnu with '-m4 -ml' supports SH4, little-endian,
and with '-m3 -mb' supports big-endian. Just don't build a little-endian
glibc and expect to link with big-endian code.
> It seems that you don't read my patch (and argument) sent to
> gcc-patches at all. Could you please read it. Is the patch is OK for
I've used that patch for a while now, but I'm in agreement with the others
that multilibs for Linux doesn't make much sense, when glibc doesn't
> Well, I explain again. My point is,
> (1) We should support following four targets in GCC which is NOT multilibbed.
> With those single specified architecture targets, you can build GCC,
> with GNU C library. To do this, I need a patch I've sent to gcc-patches.
> Do you agree this?
I have a slight problem with this. According to linux.h SH supports Linux
for the SH3E as well .. with your triplet scheme it makes it impossible to
select the sh3e as a default. Here's the scheme I came up with (to be used
with all sh triplets, not just Linux ones):
sh, sh[1-4], sh1be, sh3ele, sh3ebe, sh[2-4][bl]e
If you don't explictly set the endianness, it defaults to big-endian, which
works for the default target, sh1 big-endian. The Linux target already
defaults to sh3, little-endian, but by specifying the above triplets you
are able to easily override this.
I've been tinkering with a patch that implements this, hopefully I can have
it ready sometime today. It's a bit difficult since CVS gcc doesn't build
for sh (so far it's against gcc-3.0).
The patch doesn't add a bunch of t- fragments and header files, it does all
of it's dirty work in sh.h and linux.h (using TARGET_CPU_DEFAULT derived
from the config triplet).
> (2) Removing multilib from sh-unknown-linux-gnu is questionable for me.
> I'm afraid of it just means let the target sh-unknown-linux-gnu
> as sh3-unknown-linux-gnu.
What's wrong with that? I think the question is, going forward, do we want
users to use the config triplet to select their default? You can always
use the -m options to override the default,
> (3) If you don't like multilibbed environment, just not use
> sh-unknown-linux-gnu, which supports multiple targets.
> Instead, use single one.
You don't have a true multilib environment if the biggest component, glibc,
doesn't support it. When you go back to build the full compiler
(libiberty, libstdc++, etc.) you'll get link errors when trying to do
> (4) I believe that the target sh-unknown-linux-gnu means supporting
> four targets:
> To suppurts those four targets, it uses multilib.
No, it doesn't because as people keep reiterating, glibc doesn't use
multilibs for SH. AFAIK there is no other Standard C library that you can
use for SH Linux that does either. The only thing that would use multilibs
would be libgcc, but you end up with an incompatible system anyway as there
is only 1 glibc to link with.
> (5) Currently, GNU C library doesn't support multilibed installation.
> However, you can manually set up the environment. Compile &
> install & move for those four targets (four times).
Right. So why use multilibs on something that doesn't use it?