May be this is incorrect?

[Joel Sherrill]

Leon Pollak wrote:
> 
> Joel Sherrill wrote:
> 
> > Leon Pollak wrote:
> > >
> > > Hello, all.
> > >     I am dealing with rather tiny and specific project with
> > > RTEMS 4.5.0-beta1c and have the following problem.
> > >     File .../lib/libc/malloc.c in the line 319 calls assert(0) to abort
> > > application in the case of free() error. This causes all the stuff of
> > > printf and etc. to be included into the link process which in my case is
> > > undesired. The similar case occurs in the line 128, but  there the
> > > rtems_fatal_error_occurred() is used, which seems to be more correct.
> > > Isn't it?

THe intent at line 128 is that the system is not yet initialized so
there
is no way assert can report anything useful.  The assert at line 319 is 
later and the console is initialized.  THe choice was made based on 
most information via the error reporting mechanism.

> > This seems to be one of the nitpicky things that I was hoping to get
> > reports of. :)  Things like this are the surprising dependencies that
> > cause unneeded routines to get pulled into your executable.
> >
> > I checked this with the minimum.exe sample application but I don't see
> > printf included.  I see malloc and RTEMS_Malloc_Initialize so I know
> > we are looking at the RTEMS malloc code.  I see __assert so it is in
> > the executable.  But printf is not.  Are you sure that is the only
> > place it is referenced?
> >
> > I built for i386-rtems .. pc486 BSP .. optimized.
> >
> > You should do an objdump on your executable and search for
> > printf.   It has to be called from somewhere. :)
> 
>     Joell, this was exactly what I did and this way I came to this point.
> More than that, when I did this change, everything was O'K.
>     Now, please, how it can be that you see assert and don't see printf? I
> have it in the line 57 of my mewlib-1.8.0/newlib/libc/stdlib/assert.c

My build was using the RPMs based on newlib 1.8.2 and looks to be 
the same code for assert as that which you see in 1.8.0.

AHAH!! Some of the i386 BSPs include an __assert implementation that
calls printk and does some board specific action.  See
i386/pc386/console.c
for an example.

I have experimented with making printk a shared function.  It could
be used as the foundation of a BSP specific __assert.

Another is calling rtems_panic in this case (which still calls fprintf
<sigh>).

I don't like the idea of reducing the amount of debugging information.

> Thnks.
> leonp at plris.com

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985