Re: [linuxsh-dev] GNU CVS gcc -- fixup for -m4-nofpu

[M. R. B. <ma...@uw...>]

On Tue, 20 Feb 2001, Bryan Rittmeyer wrote:

> Hello,
> 
> For anybody else as crazy (stupid?) as me that wants to try sh4 GNU CVS
> gcc, here's a patch to fix some compiler-defined symbols when -m4-nofpu
> is used. Currently, __sh3__ is defined by -m4-nofpu, but __sh4__ is not,
> which is causing the kernel compile to fail. Here's my fixup patch for
> gcc (for -rgcc-3_0-branch):
> 
> --- gcc/config/sh/sh-old.h      Thu Feb 15 09:16:52 2001
> +++ gcc/config/sh/sh.h  Tue Feb 20 15:55:45 2001
> @@ -48,7 +48,7 @@
>  %{m3e:-D__SH3E__} \
>  %{m4-single-only:-D__SH4_SINGLE_ONLY__} \
>  %{m4-single:-D__SH4_SINGLE__} \
> -%{m4-nofpu:-D__sh3__ -D__SH4_NOFPU__} \
> +%{m4-nofpu:-D__SH4__ -D__SH4_NOFPU__} \
>  %{m4:-D__SH4__} \
> 

I had been thinking about something like this too, I'll test your patch
with the -m4-nofpu flag on, thanks.

> %{!m1:%{!m2:%{!m3:%{!m3e:%{!m4:%{!m4-single:%{!m4-single-only:%{!m4-nofpu:-D__sh1__}}}}}}}}
> \
>  %{mnomacsave:-D__NOMACSAVE__} \
> @@ -212,7 +212,7 @@
>    {"4-single", TARGET_NONE, "" },              \
>    {"4-single",
> SH4_BIT|SH3E_BIT|SH3_BIT|SH2_BIT|SH1_BIT|HARD_SH4_BIT|FPU_SINGLE_BIT, ""
> },\
>    {"4-nofpu",  TARGET_NONE, "" },              \
> -  {"4-nofpu",  SH3_BIT|SH2_BIT|SH1_BIT|HARD_SH4_BIT, "" },\
> +  {"4-nofpu",  SH4_BIT|SH3E_BIT|SH3_BIT|SH2_BIT|SH1_BIT|HARD_SH4_BIT,
> "" },\
>    {"4",                TARGET_NONE, "" },              \
>    {"4",               
> SH4_BIT|SH3E_BIT|SH3_BIT|SH2_BIT|SH1_BIT|HARD_SH4_BIT, "" }, \
>    {"b",                -LITTLE_ENDIAN_BIT, "" },       \
>

Hmm, my assumption (I could be wrong) was that SH4_BIT|SH3E_BIT weren't in
the the -m4-nofpu flag because all FP code generation is supposed to be
disabled.  The question I had asked before was, why is this flag necessary
in the kernel (e.g. what does it matter if FP code generation is active or
not), but I hadn't gotten a response (I thought it was explained before
though).  I guess what I'm saying is I think leaving those *_BITs off is
an internal gcc hack, so that it does sh4 insn scheduling, etc. but
doesn't do hardware floating-point, so that should probably stay off
(unless it's breaking something for you).
 
> is anyone else using a cvs version of gcc with good results?
> 

Yes, I admit I'm crazy to sync and build my gcc CVS nearly everyday, but
it's because different things seemed to break in kernel compilation from
day-to-day :).  But the one I tried yesterday (20010220) worked perfectly.

> Also, is anyone using a new glibc (2.2, 2.2.1, 2.2.2) with the old
> (LinuxSH CVS) binutils and gcc? I've tried to do so, but get lots of
> undefined symbols and some conflicts with libgcc when trying to link
> (staticly or dynamically). but glibc itself builds without any error.
> 

The only other issue I had with the 'sh-linux-gnu' target was that LinuxSH
decided to break ABI compatibility with the standard 'sh-unknown-elf'
flavors.  Since I'm doing amatuer Dreamcast development, most of the tools
people out there are using are targeted to 'sh-elf' (old ABI), so I've had
to maintain two sets of tools.  I have patches to create a new target,
'sh-sega-dreamcast' (which work), that currently uses sh-linux-gnu's ABI.
I was poking here and there tonite to see if it's possible in binutils and
gcc to conditionalize both ABIs and add a -mabi or -melf flag to sh.h, so
that I could use the same tools without breaking both environments.  Does
anyone have any ideas?  Are there any other archs/targets that do this? 
 Oh, by ABI I meant sh-linux-gnu doesn't require the leading underscore in
asm code while sh-elf does.

Hmm, could it be possible that the latest glibc is still using the old
ABI?  If anything the undefined symbols are references to asm modules,
just pure speculation :).

M. R.