OSDev.org

NickJohnson wrote:Just because delete() is never used doesn't necessarily mean it is not referenced anywhere, afaik. Are you using -fno-builtin?

Also, did you check which function was doing the reference? The linker should spit out the name of the previous symbol if there's an error.

pcmattman wrote:What does the function look like? Can you post some code?

namespace kernel {
        
class TestCase {
public:
        virtual void setup();
        virtual void tearDown();
        virtual void addTestPoint();

protected:
        TestCase();
        virtual ~TestCase() {}

private:
        TestCase(const TestCase&);
        const TestCase& operator=(const TestCase&);
};

} /* namespace kernel */

TestFramework doesn't have a destructor (of course, g++ generated one for me).

pcmattman wrote:

TestFramework doesn't have a destructor (of course, g++ generated one for me).

I would highly suggest not letting the compiler generate anything for you when you're writing a kernel

base object destructor of a class T: A function that runs the destructors for non-static data members of T and non-virtual direct base classes of T.
complete object destructor of a class T: A function that, in addition to the actions required of a base object destructor, runs the destructors for the virtual base classes of T.
deleting destructor of a class T: A function that, in addition to the actions required of a complete object destructor, calls the appropriate deallocation function (i.e,. operator delete) for T.

Solar wrote:...or not using virtual functions / inheritance in kernel space.

Regarding the thread title - the chance of any of us actually finding a bug in a well-used toolchain is very, very slim. For all practical purposes, I would not consider that possibility when looking for the cause of unexpected behaviour.

Colonel Kernel wrote:Visual C++ compiler back in 2003...

froggey wrote:You must implement operator delete, even if it's just panic("Can't happen!"), it's required by the C++ ABI. Every class gets 3 destructors:

base object destructor of a class T: A function that runs the destructors for non-static data members of T and non-virtual direct base classes of T.
complete object destructor of a class T: A function that, in addition to the actions required of a base object destructor, runs the destructors for the virtual base classes of T.
deleting destructor of a class T: A function that, in addition to the actions required of a complete object destructor, calls the appropriate deallocation function (i.e,. operator delete) for T.

http://www.codesourcery.com/public/cxx-abi/abi.html (I know it says "Itanium C++ ABI", but it's the same ABI that gcc uses on x86)

The only way to "fix" this is to use a compiler that uses a different ABI

ffffff00001075f3:       b8 00 00 00 00          mov    $0x0,%eax
ffffff00001075f8:       84 c0                   test   %al,%al
ffffff00001075fa:       74 14                   je     ffffff0000107610 <kernel::TestFramework::~TestFramework()+0x4c>
ffffff00001075fc:       48 8b 44 24 08          mov    0x8(%rsp),%rax
ffffff0000107601:       48 89 c7                mov    %rax,%rdi
ffffff0000107604:       48 b8 b1 5f 10 00 00    mov    $0xffffff0000105fb1,%rax /* This is operator delete() */
ffffff000010760b:       ff ff ff
ffffff000010760e:       ff d0                   callq  *%rax /* How could it be possible that we reach here ? */

How could it be possible that operator delete get called? This is what makes me confused. g++ generates code that unnecessarily depends on an operator delete() implementation. Maybe this is just a feature, not a bug.

btw: when switch -O2 is used the reference to operator delete will disappear