rtems++ failure help....

[Chris Johns]

"John S. Gwynne" wrote:
> 
> I'm trying to make progress in understanding why the rtems++ test program
> (beta3) fails on the efi332 (m68332) target.
> 
> The code fail in the rtems++ library at
> 
> rtems-4.5.0-beta3/c/src/librtems++/src/rtemsTask.cc:287
> 
> where "task->body(task->argument)" is executed.
> 
> a dump of task ("p/x *task") shows...
> 
> $6 = {<rtemsStatusCode> = {last_status = 0x0}, name = 0x54413120, name_str = {
>     0x54, 0x41, 0x31, 0x20, 0x0}, owner = 0x1, id = 0x8010002,
>   argument = 0xdeaddead, _vptr$ = 0x0}
> 
> The virtual pointer table (_vptr) is zero, which leads to my "bus
> error" when the virtual function task->body is resolved and
> executed (I think :).
> 

Looking at the code, Task1 is a global object. If you do not run static
constructors this test will fail. Maybe the test code should check for
this case.

Does the cdtest in samples run and pass ?

> It's not yet clear to me who/when this pointer should be set. When I
> try this under Linux with the posix bsp, this table resolves to
> "__vt_5Task1". Under the m68k/efi332 bsp, it looks like the table
> should point to "force_to_data" (WAG, contains _vt.5Task1) instead of
> 0x00. At what point should the virtual function table be set in the task
> class... compile/linker/loader/run time? (watch point didn't
> help... hummm...)
> 
> I would appreciate any help in understanding how virtual pointer
> tables are created and why it is wrong for this target.
> 

It depends on the nature of the object being constructed and when calls
to virtual functions occur in constructors. It has been a long time and
few releases since I looked at what gcc does. Maybe someone who actually
know what gcc does can help here. 

When a class constructs the vtable should be the one for the object
being created. As inherited classes are constructed each level sets the
virtual pointer to its vtable.

A pure virtual function complicates the handling of tables. I have seen
compilers not set the vtable pointer or point to a "pure virtual"
function trap.

-- 
 Chris Johns, mailto:cjohns at cybertec.com.au mailto:ccj at acm.org