Problems with RTEMS-4.7.1 pc386 BSP

Joel Sherrill joel.sherrill at
Thu May 24 15:56:19 UTC 2007

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:
>         rtems-4-7-branch:
> => 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.

> Ralf

More information about the users mailing list