[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Problems with RTEMS-4.7.1 pc386 BSP
- Date: Thu, 24 May 2007 10:56:19 -0500
- From: joel.sherrill at oarcorp.com (Joel Sherrill)
- Subject: Problems with RTEMS-4.7.1 pc386 BSP
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.