rtems++ failure help....

Chris Johns cjohns at cybertec.com.au
Mon May 22 07:05:01 UTC 2000

"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

More information about the users mailing list