search

Samraksh / eMote

eMote OS -- Multiple Ports (using .NET MF v4.3)
0 stars 0 forks source link

Basic Inheritance not working #478

Open BoraAtSamraksh opened 6 years ago

BoraAtSamraksh commented 6 years ago

I've noticed that basic inheritance with virtual functions not working. I've created a native test to demonstrate the issue (TestSuite/Misc/InheritanceTest).

Currently it crashes when a virtual function is called from within another method of the base class. More specifically it crashes on InheritanceTestObjectt.h::19.

There might be some easy mistake that I miss somewhere. Please let me know if you notice it.

Nathan-Stohs commented 6 years ago

What version of GCC are you running? Are there any warnings given in the build output?

Nathan-Stohs commented 6 years ago

After thinking a bit, my intuition is that this is broken because we don't have full C++ runtime support in MF. In particular we don't really have dynamic memory. This is probably necessary for RTTI. We already disable exceptions for similar reasons. Arguably we should add -fno-rtti as well.

BoraAtSamraksh commented 6 years ago

I've tried both with GCC6.3.1 and GCC5.4.1. There are no warnings in the build output.

Nathan-Stohs commented 6 years ago

I stand by my earlier comment about not having dynamic memory being the problem... but if you want to try something, make gInheritanceTest not global. I'm questioning if its constructor (as a global) is being run. I thought we fixed that at some point but maybe not.

ChrisAtSamraksh commented 6 years ago

There is a core problem where global class constructors are not being called. I think this is related to another problem where virtual functions called from within a base class will cause hard faults. Perhaps we are supposed to be running some code that runs constructors or there is a problem with the virtual tables.

I also had to add the two compiler flags : -fno-rtti -fno-use-cxa-atexit

There is a work around where we can instantiate a static local class and then have a global pointer to that class. This will have the constructors be run and allow the virtual functions to be called from within the base classes. The drawback is that this class is put on the stack and not the heap.

Nathan-Stohs commented 6 years ago

...Perhaps we are supposed to be running some code that runs constructors...

It is incumbent on us, as the runtime, to do this if we aren't doing it already. If this is true, likely we've skated by because simple zero-init was enough. MF is written in C++ but except for a few templates its basically C.

I also had to add the two compiler flags : -fno-rtti -fno-use-cxa-atexit

I'd imagine that -fno-rtti would prevent virtual functions from working at all, even with the work-around, have you tried it? I'm not a C++ expert so maybe its not required in some circumstances...

ChrisAtSamraksh commented 6 years ago

Wouldn't this be part of MF already? Did we not implement something that is a part of MF?

Nathan-Stohs commented 6 years ago

Wouldn't this be part of MF already? Did we not implement something that is a part of MF?

MF is about a half-step above library / language issues such as this. Technically it's on us to do it during the port as its quasi platform specific. I say only "half" because MF does provide some examples and suggestions as part of the porting kit and build setup.

AFAIK, MF doesn't make much use of C++ beyond a few half-hearted templates. I don't think you will find a new anywhere in the code but I could be wrong. So its possible we are exercising new stuff.