This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: GAS patch for sh*-unknown-linux-gnu
- To: Hans-Peter Nilsson <hp at bitrange dot com>
- Subject: Re: GAS patch for sh*-unknown-linux-gnu
- From: Ralf Corsepius <corsepiu at faw dot uni-ulm dot de>
- Date: 16 Oct 2001 07:40:52 +0200
- Cc: NIIBE Yutaka <gniibe at m17n dot org>, binutils at sources dot redhat dot com, bje at redhat dot com, Joel Sherrill <joel dot sherrill at OARcorp dot com>
- References: <Pine.BSF.4.30.0110152256550.87282-100000@dair.pair.com>
Am Die, 2001-10-16 um 05.09 schrieb Hans-Peter Nilsson:
> On Wed, 3 Oct 2001, NIIBE Yutaka wrote:
>
> > Here's a patch for gas for the target sh*-unknown-linux-gnu.
>
> > Besides, we'd like to set default as little endian for
> > sh-unknown-linux-gnu, because it's more populer for SH-3 and SH-4.
>
> To me, it seems that you (Niibe) are right in that sh-linux is
> always little-endian. Refer to ASM_SPEC in
> gcc/config/sh/linux.h. Making it the default for sh-linux seems
> it would only make things simpler, for people who need to write
> mixed assembly and C.
IMHO, this is only partially correct.
The default for the sh been bigendian. Therefore users and applications
are used to using gcc -ml and to using __LITTLE_ENDIAN__ and such.
> I'm not really sure about using "sh*eb-*-linux*" to denote a
> GNU/Linux system using big endian code and data. Is this triple
> new or has it been used somewhere else? I'm not sure I can
> approve it if it's new. Do we need it; do you know of any
> GNU/Linux big endian variant? It's not used in e.g. bfd. Is
> there an existing (non-SH-based) port where sh* would collide?
> Can Ben Elliston, the config.* maintainer, shed some light?
Sorry, I don't know, but I am inclined to agree with you (i.e. to reject
the sh-*eb* part).
> I'd like to hear if the sh-linux change of default would
> actually cause people any problems. Ralf Corsepius, you were
> opposed to this change. Do you have a big-endian SH-based port,
Depends on what you are referring to.
No, I don't have a big-endian sh-linux port nor am I using sh-linux.
I am the original porter of RTEMS to the sh and the
"defacto/inofficial"-maintainer of sh-rtems. RTEMS currently supports
sh1/sh2 big endian (little endian is supposed to work, but has never
been used, AFAIK), I heared about sh3-ports (RTEMS can be used closed
source), furthermore, an sh4/little endian port currently is being
merged into the public sources.
The GNU-toolchains being used for all of them is more or less identical
to default sh-coff and sh-elf gcc/GNU-toolchains, ie. multilibbed, with
big-endian being the default for all cpu-variants.
> or do you think this change would be bad for other reasons than
> there would then be different default-endians among sh-*-*
> ELF-based targets?
This part of your sentence is the quintessence of what I tried to
express: I am concerned about inconsistent defaults for different
sh-*-binutils and complications arizing from this. All I want is
simplicity wrt. portability, but I am not particularily concerned about
sh-*-linux-gnu.
I just want to avoid complaints like these: "WTH does sh-rtems-as
require -ml, while sh-*linux-as doesn't. Now, I need to hack my
source-tree to get that d***ed stuff working?"
If you feel comfortable with this, please go ahead. As such low-level
libraries and applications will rare be met, this issue will only affect
a very small number of users, anyway :(
Ralf