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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
