Re: GAS patch for sh*-unknown-linux-gnu

[Ralf Corsepius <corsepiu at faw dot uni-ulm dot de>]

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