SIZE_TYPE predefine not following CPU flags on embedded mips

SIZE_TYPE predefine not following CPU flags on embedded mips

[Joel Sherrill]

Hi,

I am trying to add some more multilibs to the mips-elf
and mips-rtems targets.  I want mips1 and mips3 libraries.
I have changed these lines in mips/config/t-elf:

MULTILIB_OPTIONS = msoft-float/msingle-float EL/EB
MULTILIB_DIRNAMES = soft-float single el eb

to this:

MULTILIB_OPTIONS = mips1/mips3 msoft-float/msingle-float EL/EB
MULTILIB_DIRNAMES = mips1 mips3 soft-float single el eb

In gcc 3.2.1 for the targets mips-elf and mips-rtems, the 
setting of __SIZE_TYPE__ does not appear to be changed
as expected by the file libstdc++-v3/libsupc++/del_op.cc.
The above multilibs result in a compile with just a -mips3 and
the build dies with this error:

In file included from
../../../../../gcc-3.2.1/libstdc++-v3/libsupc++/del_op.cc:31:
../../../../../gcc-3.2.1/libstdc++-v3/libsupc++/new:79: `operator new'
takes
   type `size_t' (`long unsigned int') as first parameter

I have tracked this down to size_t being an "unsigned int".
NO_BUILTIN_SIZE_TYPE is set in the mips config
files and the specs I see with -dumpspecs appear to
trip on the combination "-mabi=eabi -mips3" instead of just
-mips3.  

This is in an odd corner of the mips port and I don't the right
thing to do.  Help would definitely be appreciated.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: SIZE_TYPE predefine not following CPU flags on embedded mips

[Neil Booth]

Joel Sherrill wrote:-

> I have tracked this down to size_t being an "unsigned int".
> NO_BUILTIN_SIZE_TYPE is set in the mips config
> files and the specs I see with -dumpspecs appear to
> trip on the combination "-mabi=eabi -mips3" instead of just
> -mips3.  
> 
> This is in an odd corner of the mips port and I don't the right
> thing to do.  Help would definitely be appreciated.

Does GCC 3.3 get it right?  It should do.  Do you really need it
to work in 3.2?  The problem will be in the SPECS in the header file.

Neil.

Re: SIZE_TYPE predefine not following CPU flags on embedded mips

[Eric Christopher]

> Does GCC 3.3 get it right?  It should do.  Do you really need it
> to work in 3.2?  The problem will be in the SPECS in the header file.
> 

I agree. This is _much_ easier in 3.3 if it's broken. It should work
there. Please file a bug if it doesn't.

-eric

ps. I'd use mips64-elf for this btw since there are elf64.h bits that
don't work in plain mips-elf.

-- 
Yeah, I used to play basketball...

Re: SIZE_TYPE predefine not following CPU flags on embedded mips

[Joel Sherrill]

Eric Christopher wrote:
> 
> > Does GCC 3.3 get it right?  It should do.  Do you really need it
> > to work in 3.2?  The problem will be in the SPECS in the header file.
> >
> 
> I agree. This is _much_ easier in 3.3 if it's broken. It should work
> there. Please file a bug if it doesn't.

OK.  I just checked everything out fresh from the 3.3 branch.

> -eric
> 
> ps. I'd use mips64-elf for this btw since there are elf64.h bits that
> don't work in plain mips-elf.

My goal is to have just one toolset target that can produce mips1
and mips3 executables.  Are you saying that this is impossible?

Am I going to always have to have mips-rtems and mips64-rtems 
toolsets? :(

> --
> Yeah, I used to play basketball...

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: SIZE_TYPE predefine not following CPU flags on embedded mips

[Eric Christopher]

> 
> My goal is to have just one toolset target that can produce mips1
> and mips3 executables.  Are you saying that this is impossible?
> 

It's getting less so as we go on. In fact I was just looking at the
differences between elf64.h and elf.h today. It's pretty much just
related to sbss and sdata. (Basically that elf64.h doesn't have sbss)

> Am I going to always have to have mips-rtems and mips64-rtems 
> toolsets? :(
> 

Definitely not.

-eric

-- 
Yeah, I used to play basketball...

Re: SIZE_TYPE predefine not following CPU flags on embedded mips

[Joel Sherrill]

Eric Christopher wrote:
> 
> >
> > My goal is to have just one toolset target that can produce mips1
> > and mips3 executables.  Are you saying that this is impossible?
> >
> 
> It's getting less so as we go on. In fact I was just looking at the
> differences between elf64.h and elf.h today. It's pretty much just
> related to sbss and sdata. (Basically that elf64.h doesn't have sbss)

Great.  

> > Am I going to always have to have mips-rtems and mips64-rtems
> > toolsets? :(
> 
> Definitely not.

YEAH!

For now, should I have them though?

> -eric
> 
> --
> Yeah, I used to play basketball...

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

Re: SIZE_TYPE predefine not following CPU flags on embedded mips

[Eric Christopher]

[-- Attachment #1: Type: text/plain, Size: 551 bytes --]


> > > Am I going to always have to have mips-rtems and mips64-rtems
> > > toolsets? :(
> > 
> > Definitely not.
> 
> YEAH!
> 
> For now, should I have them though?
> 

Here you go. Now the only reason you should want it is to set defaults.
This is from the mips-3_4-rewrite-branch code but should apply fairly
cleanly to current mainline. Be careful about the multilib selection for
the t-file.

Caveat: I haven't really run a lot of testing on this :)

-eric

ps. the rest of the patch is removing elf64.h

-- 
Yeah, I used to play basketball...




[-- Attachment #2: mips.dead.diff --]
[-- Type: text/x-patch, Size: 1823 bytes --]

Index: config.gcc
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config.gcc,v
retrieving revision 1.246.2.6
diff -u -p -w -r1.246.2.6 config.gcc
--- config.gcc	9 Jan 2003 01:19:34 -0000	1.246.2.6
+++ config.gcc	9 Jan 2003 01:55:34 -0000
@@ -1856,28 +1856,26 @@ mips-*-elf* | mipsel-*-elf*)
 	tmake_file=mips/t-elf
 	;;
 mips64-*-elf* | mips64el-*-elf*)
-	tm_file="${tm_file} mips/elf64.h"
+	tm_file="${tm_file} mips/elf.h"
 	tmake_file=mips/t-elf
 	target_cpu_default="MASK_64BIT|MASK_FLOAT64|MASK_GAS"
 	tm_defines="MIPS_ISA_DEFAULT=3 MIPS_ABI_DEFAULT=ABI_O64"
 	;;
 mips64vr-*-elf* | mips64vrel-*-elf*)
-        tm_file="mips/vr.h ${tm_file} mips/elf64.h"
+        tm_file="mips/vr.h ${tm_file} mips/elf.h"
         tm_defines="MIPS_ABI_DEFAULT=ABI_O64 MIPS_MARCH_CONTROLS_SOFT_FLOAT=1"
         tmake_file=mips/t-vr
         ;;
 mips64orion-*-elf* | mips64orionel-*-elf*)
-	tm_file="${tm_file} mips/elforion.h mips/elf64.h"
-	tmake_file=mips/t-elf
+	tm_file="${tm_file} mips/elforion.h mips/elf.h"
 	tmake_file=mips/t-elf
 	target_cpu_default="MASK_64BIT|MASK_FLOAT64|MASK_GAS"
 	tm_defines="MIPS_ISA_DEFAULT=3 MIPS_ABI_DEFAULT=ABI_O64"
 	;;
 mips64orion-*-rtems*)
 	xm_defines=POSIX
-	tm_file="${tm_file} mips/elforion.h mips/elf64.h mips/rtems64.h rtems.h"
+	tm_file="${tm_file} mips/elforion.h mips/elf.h mips/rtems64.h rtems.h"
 	tmake_file="mips/t-elf t-rtems"
-	tmake_file=mips/t-elf
 	target_cpu_default="MASK_64BIT|MASK_FLOAT64|MASK_GAS"
 	tm_defines="MIPS_ISA_DEFAULT=3 MIPS_ABI_DEFAULT=ABI_O64"
 	if test x$enable_threads = xyes; then
@@ -2818,7 +2816,7 @@ mips*-*-*)
 			;;
 	esac
 	case $tm_file in
-		*mips/elf.h* | *mips/elf64.h*)
+		*mips/elf.h*)
 			tm_defines="OBJECT_FORMAT_ELF $tm_defines"
 			;;
 	esac

Re: SIZE_TYPE predefine not following CPU flags on embedded mips

[Joel Sherrill]

Neil Booth wrote:
> 
> Joel Sherrill wrote:-
> 
> > I have tracked this down to size_t being an "unsigned int".
> > NO_BUILTIN_SIZE_TYPE is set in the mips config
> > files and the specs I see with -dumpspecs appear to
> > trip on the combination "-mabi=eabi -mips3" instead of just
> > -mips3.
> >
> > This is in an odd corner of the mips port and I don't the right
> > thing to do.  Help would definitely be appreciated.
> 
> Does GCC 3.3 get it right?  It should do.

It does work well enough to let me add the mips3 multilib variants,
successfully build the compiler, and link the application that would
not link before because it couldn't find a mips3 libc.a.

>  Do you really need it
> to work in 3.2?  The problem will be in the SPECS in the header file.

No.  RTEMS keeps up with gcc releases so if I can successfully
use gcc 3.3 with Eric's patch to address the remaining issues
he knew of, then I am happy.

When the MIPS rework is merged into the trunk will it be OK for
mips-elf to build mips3 variants also?  

Also I noticed that in the 3.3 branch, the multilib match for
4650 is gone.  What is the proper way to compile and link for
a 4600/4650 these days?

> Neil.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985