RTEMS 4.11: Tool Chain

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