Strange problem with newlib strstr function and rtems 4.10 on coldfire

[Paul Whitfield]

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 was just interested in making sure it was in the
next release.

Thanks a million!


-- 
Message  protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg