Problems with RTEMS-4.7.1 pc386 BSP

[Ralf Corsepius]

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: 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.

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
assert().


> 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
replace __assert.

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
miss-compiled)
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
use.

Ralf