Problems with RTEMS-4.7.1 pc386 BSP
joel.sherrill at oarcorp.com
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: 220.127.116.11
> rtems-4-7-branch: 18.104.22.168
> => 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
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.
More information about the users