RTEMS 4.11: Tool Chain

Sebastian Huber sebastian.huber at embedded-brains.de
Wed Feb 5 08:01:01 UTC 2014


On 2014-02-04 18:50, Ralf Corsepius wrote:
> On 02/04/2014 04:13 PM, Sebastian Huber wrote:
>> Hello,
>>
>> we have to define the tool chain versions intended for RTEMS 4.11.
>>
>> For Binutils I would like to use release 2.24 with the attached patch.
>>
>> For GCC we should use a recent 4.8 branch snapshot (e.g.
>> ftp://ftp.gwdg.de/pub/misc/gcc/snapshots/4.8-20140130/gcc-4.8-20140130.tar.bz2)
>> and use GCC 4.8.3 for the release.  This gives us also some time to test
>> the RTEMS 4.11 branch, which we should create soon.
>>
>> In the GCC 4.8.2 release there are several SPARC specific patches not
>> included which are part of the GCC 4.8 branch.  We should submit all
>> outstanding GCC patches upstream before the GCC 4.8.3 release.
>>
>> This GCC patch change is still open:
>>
>> http://www.rtems.org/pipermail/rtems-devel/2013-April/002868.html
>>
>> See also:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47111
> Well, IMO, this is a general rtems-independent bug in the mips port.
>
> When trying to have it fixed in GCC, some years ago, the mips maintainers
> refused to apply it.
>
> So, one may undef it for rtems as a work-around, but this is just playing with
> symptoms and with a cure to the cause.

Ok, but we have now this workaround in upstream GCC, so there is no need to 
keep the patch.

>
>> This is also an open issue:
>>
>> http://www.rtems.org/pipermail/rtems-devel/2013-April/002830.html
> Right, these patches should be upstreamed.

We should first determine why we need these patches.

The default seems to be:

gcc/defaults.h:#ifndef WCHAR_TYPE_SIZE
gcc/defaults.h:#define WCHAR_TYPE_SIZE INT_TYPE_SIZE
gcc/defaults.h:#ifndef WCHAR_TYPE
gcc/defaults.h:#define WCHAR_TYPE "int"

On m32c we have:

gcc/config/m32c/m32c.h:#undef  WCHAR_TYPE
gcc/config/m32c/m32c.h:#define WCHAR_TYPE "long int"
gcc/config/m32c/m32c.h:#undef  WCHAR_TYPE_SIZE
gcc/config/m32c/m32c.h:#define WCHAR_TYPE_SIZE 32

On m68k we have:

gcc/config/m68k/m68k.h:#define WCHAR_TYPE "long int"
gcc/config/m68k/m68k.h:#define WCHAR_TYPE_SIZE 32

On sh we have:

gcc/config/sh/sh.h:#define WCHAR_TYPE "short unsigned int"
gcc/config/sh/sh.h:#define WCHAR_TYPE_SIZE 16
gcc/config/sh/sh.h:#define SH_ELF_WCHAR_TYPE "long int"
gcc/config/sh/elf.h:#undef WCHAR_TYPE
gcc/config/sh/elf.h:#define WCHAR_TYPE SH_ELF_WCHAR_TYPE
gcc/config/sh/elf.h:#undef WCHAR_TYPE_SIZE
gcc/config/sh/elf.h:#define WCHAR_TYPE_SIZE 32

On sparc we have:

gcc/config/sparc/sparc.h:#define WCHAR_TYPE "short unsigned int"
gcc/config/sparc/sparc.h:#define WCHAR_TYPE_SIZE 16
gcc/config/sparc/sp-elf.h:#undef WCHAR_TYPE
gcc/config/sparc/sp-elf.h:#define WCHAR_TYPE "long int"
gcc/config/sparc/sp-elf.h:#undef WCHAR_TYPE_SIZE
gcc/config/sparc/sp-elf.h:#define WCHAR_TYPE_SIZE BITS_PER_WORD

On v850 we have:

gcc/config/v850/v850.h:#undef  WCHAR_TYPE
gcc/config/v850/v850.h:#define WCHAR_TYPE "long int"
gcc/config/v850/v850.h:#undef  WCHAR_TYPE_SIZE
gcc/config/v850/v850.h:#define WCHAR_TYPE_SIZE BITS_PER_WORD

So to me this seems that the architecture specific headers use "long int" 
instead of the default "int" for WCHAR_TYPE.  What is wrong with this?

>
>> For Newlib I would use 2.1.0 without any patches or a recent snapshot.
> My trust in newlib-2.x is fairly low, because of the amount of changes it has
> seen and because it still has not stabilized enough to allow proper testing.

I use the Newlib HEAD now for two years or so and addressed all problems I 
found.  The only remaining issue I am aware of is:

https://www.rtems.org/bugzilla/show_bug.cgi?id=1247

>
> Finally, FYI: Some weeks ago I attempted a stab on porting the rtems-tools
> chains to x86_64-cygwin, but was badly hit by what I currently assume to be a
> bug in cyginw's newlib-2.0, which seems to originate from one of these changes.
> However, I am not sure about it, yet.

Ok, but this is a Cygwin problem?

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.



More information about the devel mailing list