[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

cdtest fails

Joel Sherrill wrote:

> > I had the same problems testing hello with the C++ version. I've got the
> > rtems-ctor.cc integrated with the bspstart now -- hello runs properly without
> > defining a bunch of semaphores.  However, I had to include some definitions
> > is the extern "C" { section to get it to go:
> >
> > extern void bsp_start(void);
> > extern void bsp_cleanup(void);
> > extern unsigned32 bsp_isr_level;
> >
> > So, yes I guess this means I am using the 'C' startup procedure.
> If the cglobal constructors get run, then you are using the C++ version.
> Are you getting to __main?

The __do_global_ctors function does get called.

> > I also found an error in the startup code of the original bsp.  This was
> > really stupid:  I managed to create the heap such that it redefined the
> > stack.  The stack was at the bottom of the heap.  I think this is only a
> > problem if you use a lot of heap which I did -- intermittently.  I bet that
> > some of my driver problems were related to this bug.  Anyway, I believe I
> > have fixed it now.
> We have done that before.  It is ugly and hard to find.  It could have
> been a factor in any number of problems you saw.
> > However, the cdtest does not run!  It is  still ( again ? ) failing during a
> > CPU_Context_switch, where it executes a return and

Oops.  It's ironic, but the CPU_Context_switch was returning to nothing.

This appears in the rtems-ctor.cc file as a description of the flow of control.

 *    host crt0
 *      main()
 *          __main()
 *              __do_global_ctors()
 *                  bsp_start()
 *                      init_executive_early()
 *                  <<any other constructors>>
 *          rtems_init_executive_late()
 *          bsp_cleanup()

The __do_global_ctors function IS running, BUT at this point, libc has not been
initialized.. it is initialized via init_executive_early through the funtion
bsp_libc_init.  Hence printf, malloc etc all cannot/don/t work.  I traced the
error to a malloc failure in __eh_alloc.

I am assuming that crt0 contains the necessary malloc/printf stuff.  However,
since I do NOT have a crt0,  it looks like C++ support  is impossible for my
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vcard.vcf
Type: text/x-vcard
Size: 291 bytes
Desc: Card for Erik Ivanenko
Url : http://rtems.rtems.org/pipermail/rtems-users/attachments/19980317/14aabe95/attachment.vcf