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