Strange problem with newlib strstr function and rtems 4.10 on coldfire

Wed Apr 20 13:52:20 UTC 2011

On 04/19/2011 11:52 PM, Paul Whitfield wrote:
> On 20/04/2011 12:02 PM, Ralf Corsepius wrote:
>> On 04/20/2011 03:13 AM, Paul Whitfield wrote:
>>> On 18/04/2011 5:21 PM, Ralf Corsepius wrote:
>>>> On 04/18/2011 10:16 AM, Paul Whitfield wrote:
>>>>> On 18/04/2011 2:53 PM, Ralf Corsepius wrote:
>>>>>> On 04/18/2011 06:28 AM, Paul Whitfield wrote:
>>>>>>> On 18/04/2011 10:51 AM, Paul Whitfield wrote:
>>>>>>> I have checked the newlib CVS and the version of strstr.c and
>>>>>>> str-two-way.h in RTEMS4-10 are update to date with the most current
>>>>>>> version.
>>>>>>>
>>>>>>> One last note: Recompiling the strstr.c / str-two-way.h code newlib
>>>>>>> code
>>>>>>> on the PC the code works correctly with the optimised version.
>>>>>> Are you trying to express you can reproduce your issue on PC?
>>>>>>
>>>>>> I just tried, but I can't reproduce it.
>>>>>>
>>>>>> Ralf
>>>>> Sorry I was unclear. No I can NOT reproduce the problem on the PC.
>>>> OK.
>>>>
>>>>> I have done some more investigation ...
>>>>>
>>>>> PLEASE NOTE:
>>>>> I did NOT build gcc / newlib from source.
>>>>>
>>>>> I am using the pre-compiled version from
>>>>> ftp://ftp.rtems.org//pub/rtems/mingw32/4.10/
>>>>> and it is behaving the same way as the code I am compiling here.
>>>>>
>>>>> I did some searching and found a similar symptom to what I have
>>>>> been seeing.
>>>>>
>>>>> It seems to be the strstr code is breaking because it expects the value
>>>>> of the macro SIZE_MAX to be the maximum value of a size_t variable
>>>>> however it appears that using the standard RTEMS include files,
>>>>> SIZE_MAX is actually 32.
>>>>>
>>>> You are right on the spot. SIZE_MAX is wrong.
>>>>
>>>>> Is something broken about how newlib has been built?
>>>> Not quite.
>>>>
>>>> It's a bug in our stdint.h which gets exposed when using newlib with
>>>> gcc-4.4.x. It does not get exposed with newer gccs (e.g. rtems4.11),
>>>> because the preprocessor takes a different path, then.
>>>>
>>>> I'll further investigate and try to come up with a fix. - I recall us
>>>> having had this issue before and thought I had fixed it. Apparently
>>>> not ;)
>>>>
>>>> Ralf
>>> Hi Ralf / All,
>>>
>>> Would it be helpful if I raised a bug report for this ?
>> Patience, please, ... an "emergency bug fix", which hopefully resolves
>> this issue, is on its way, but building the toolchains takes time.
>>
>> The patch already is in CVS, most Linux packages already have been
>> updated[1] and the mingw/cygwin toolchains are building.
>>
>> If things work out as desired, the mingw32 packages will land within the
>> next couple of hours.
>>
>> Ralf
>>
>> [1] All distros but Fedora 15 - The Fedora 15 builts failed for reasons
>> still to be investigated, but unrelated to this issue.
>>
> Wow! Ralf, I was not expect such a rapid response at all!
>
I don't think most people in the community realize what goes
on quietly behind the scenes for the tools. When someone installs
a pre-built toolset, it is the result of Ralf's ongoing effort.

There are build machines at OAR which Ralf has access to.  When
there is a change in a patch or tool revision, he very quickly responds
and kicks off tool builds.  I have no idea how long it takes
for them to finish building but consider the multipliers:

+ number of target architectures (~10-12)
+ number of host OS distributions and versions
    - SUSE
    - CentOS/RHEL
    - Fedora
    - mingw32
    - Cygwin
+ 32 and 64 bit hosts

Right now, I see 15 unique hosts for 4.11.  There are ~25GB
of tool content for 4.11 on ftp.rtems.org.

Ralf is very quick and RTEMS is typically the first project to
release binary tools after a binutils, gcc, or gdb release.
For gcc 4.6.0, he tracked the final release candidates so
we were using the release image before the announcement. :-D

After the tools land, there are two yum mirrors of the rtems.org
site:

+ rtems.eu [1]
+ rtems.info [2]

It can take hours for the mirror process to complete.  Ralf
has a script that monitors the mirrors and emails those interested
when things get out of sync.  A mirror out of sync is taken out of
the yum mirror list until it is resynchronized.  When a tool build
is under way, we might get email for 8+ hours showing the
progress of the synchronization.

Check out the Munin performance graphs for rtems.info to see how
long the recent tool mirroring took

> I was just interested in making sure it was in the
> next release.
>
> Thanks a million!
>
>

Ditto.  Thanks Ralf.

--joel

[1] rtems.eu is sponsored by Embedded Brains.  I don't know its
speed.

[2] rtems.info is my personal server and is sponsored by love and
donations.  It is an 8/1 Mbps connection which could be upgraded.

-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985