Problems with RTEMS-4.7.1 pc386 BSP
ralf.corsepius at rtems.org
Thu May 24 16:16:45 UTC 2007
On Thu, 2007-05-24 at 10:56 -0500, Joel Sherrill wrote:
> 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: 126.96.36.199
> > rtems-4-7-branch: 188.8.131.52
> > => 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.
assert() is POSIX.
What you are doing is to override assert with a function based on a so
far non-mandatory function printk().
I.e. you have implicitly made printk part of the API and have broken
> 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?
What ever you prefer. The issue is not assert, it is you trying to
How about a kassert?
> The newlib one called abort() which also
> brings the system down.
The newlib one is
a) not being used by newlib binaries (except the toolchain is
b) not being used, with -DNDEBUG
c) not being used by apps, except they explictly request it.
> 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.
No, it isn't. You've broken the API the BSP had been relying upon.
Whether a BSP specific assert makes sense, is a different question.
According to POSIX, assert must be a define, so redefining is a legimate
More information about the users