RTEMS 4.11: Tool Chain

Ralf Corsepius ralf.corsepius at rtems.org
Wed Feb 5 09:17:43 UTC 2014


On 02/05/2014 09:01 AM, Sebastian Huber wrote:
> 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.
As I said before, this work-around actually is wrong.

It's a new bug to pamper an old bug.


>>> 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?

Type symmetry as required by GCC's fprintf and newlib (esp. 
stdint.h/inttypes.h).

I would not want to exclude these patches have become obsolete, because 
I haven't been trying gcc-4.9/newlib-2.x, but at least up to 
gcc-4.7.x/newlib-1.2.x these were necessary.

Unfortunately, I have not been able to catch up yet, because the 
stdint.h/inttypes.h changes in newlib have broken much of my work on 
stdint/inttypes and gcc-types and pushed me back by ca. 2 years of work.

>>> 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?

I currently believe it's a general bug in newlib, they inherited from 
newlib which likely is triggered by Cross-building GCC for 
Linux->Cygwin. Unfortunately, I also haven't found enough time to 
furtherly investigate this, but am wondering why the cygwin folks have 
not yet stumbled over this bug, themselves.

Ralf





More information about the devel mailing list