Problems with RTEMS-4.7.1 pc386 BSP

[Joel Sherrill]

Ralf Corsepius wrote:
> On Thu, 2007-05-24 at 08:17 -0500, Joel Sherrill wrote:
>   
>> Till Straumann wrote:
>>     
>>> I build with this BSP occasionally but haven't upgraded to 4.7.1yet
>>> libcsupport/src/__assert.c was apparently added to 4.7.1(but was
>>> missing from 4.7.0) on 2007/3/28 so it's relatively new.
>>>
>>>   
>>>       
>> Yes it is new.  The __assert in newlib used printf so was almost guaranteed
>> to be unable to print when you needed to assert.
>>     
> Why has this change been introduced to 4.7.x?
>
> It apparent was added post 4.7.0:
>         rtems-4-7-1: 1.1.2.2
>         rtems-4-7-branch: 1.1.0.2
>
> => You've broken the API.
>
>   
__assert is not part of a public API as far as I know.  The
pc386 should not have been overriding this routine.

Since the __assert used was the newlib one, it used printf which
is not allowed to be used from most of the places where RTEMS had
asserts.  So the default __assert was effectively broken.
>> The RTEMS __assert ends with rtems_fatal_error_occurred so it makes
>> sense to me that the pc386 BSP provide a fatal error handler and use
>> the default _assert.
>>     
> Frankly speaking, I don't like this approach.
>   
What should assert call?  The newlib one called abort() which also
brings the system down. 

The goal was to provide a functional __assert which could be
called from anywhere, did not assume that the C library and
stdio were still usable and functional.  Even in the best scenario,
if you were using an interrupt driven console and called __assert
cleanly from a task, the system could be shutdown before the output
went out.

It's a dying gasp from a system and this increased the odds of it getting
out.  The pc386 BSP is broken by overriding it.

--joel
> Ralf
>
>
>