Is C++ virtual function unavailable in kernel programming?

[RichardC1ay]

Hello
I am currently programming with virtual functions but every time I call the virtual functions, it generates interrupt 6 (Invalid Opcode).

Code: Select all

void Console::Refresh()
{
    m_Init = true;
    m_KeyModifiers = 0;

    m_TextPresenter->Clear();   [b]<--- Here[/b]
    RenderModifiers();
    m_TextPresenter->Text({ 0, 2 }, '>', 15, 0);
}

TextModePresenter m_TextPresenter is a class inherit from base class VideoPresenter, and it overrides pure virtual function Clear()

Code: Select all

class VideoPresenter
{
public:
    virtual void Clear() = 0;
    ...
}; // Video.h
class TextModePresenter : public VideoPresenter
{
private:
    ...
public:
    virtual void Clear();
    ...
}; // TextModePresenter.h

void TextModePresenter::Clear()
{
    for (int y = 0; y < 25; y++)
    {
        for (int x = 0; x < 80; x++)
        {
            m_TextBuffer[(y * 80) + x] = 0x00;
        }
    }
} // TextModePresenterImpl.cc

The assembly code when problem occurs are

Code: Select all

sub $0x8, %rsp
movb $0x1,0x18(%rdi)   <---Here
movb $0x0,0x8(%rdi)

I have no idea why it generates exception.
In addition, I found that sometimes it also works correctly (I modified and compiled many times). Have anyone got same problem ever?

According to the explanation about Invalid Opcode, the value of instruction pointer (rip) is 0x16 (push?)
All my source code are commited to GitHubhttps://github.com/0x1021A0/NiteProject
I have asked my linker to generate the map, the value of stack pointer is 0xFFFFFFFF801064BC (0x1DC in ConsoleImpl.o), Now it points to

Code: Select all

1D7:  mov (%rdi),%rax
1DA:  call *(%rax)
1DC:  mov %rbx,%rdi    <---Here
1DF:  movabs $0x0,%rax

I suppose there would be some misunderstanding.

---Update 20230328---
There won't be any issue if I call the virtual function in the class constructor, but every time I try to call it in the other function, it crashes. Calling the function within the constructor also not work.

Code: Select all

Console::Console()
  : m_KeyModifiers(0),
    m_TextPresenter(new Video::TextModePresenter()),
    m_Buffers(new uint8_t[23 * 80]),
    m_OffsetX(1),
    m_OffsetY(0)
{ 
    m_TextPresenter->Clear();
}

This one works correctly, no interrupt generated.

Code: Select all

Console::Console()
  : m_KeyModifiers(0),
    m_TextPresenter(new Video::TextModePresenter()),
    m_Buffers(new uint8_t[23 * 80]),
    m_OffsetX(1),
    m_OffsetY(0)
{ 
    Refresh();
}

void Console::Refresh()
{
    m_TextPresenter->Clear();
}

Code: Select all

Console::Console()
  : m_KeyModifiers(0),
    m_TextPresenter(new Video::TextModePresenter()),
    m_Buffers(new uint8_t[23 * 80]),
    m_OffsetX(1),
    m_OffsetY(0) { }
///////////////////////////////////// 
(new Console())->Refresh();   <--- In other function

These two examples are NOT OK, it generates invalid opcode.

[Demindiro]

Virtual functions are certainly available. a vtable is simply a list of function pointers (+ some other data, maybe).

#UD implies the processor doesn't recognize the instruction. Given that the encoding of `movb $0x1,0x18(%rdi)` is the same for protected and long mode my suspicion is that for whatever reason the vtable isn't properly set up and points to garbage. It's hard to say without access to the source code though.

[Octocontrabass]

the value of stack pointer is 0xFFFFFFFF801064BC (0x1DC in ConsoleImpl.o),

That sounds like a stack overflow. The stack pointer should always have a value somewhere between stack_bottom and stack_top.

[RichardC1ay]

the value of stack pointer is 0xFFFFFFFF801064BC (0x1DC in ConsoleImpl.o),

That sounds like a stack overflow. The stack pointer should always have a value somewhere between stack_bottom and stack_top.

I think it didn't. The linker map shows that my stack is lay between 0xffffffff80522090 (stack_bottom) and 0xffffffff8052a090 (stack_top). The information I provided might be misleading, to be specific, the stack pointer is now stay at 0xFFFFFFFF80529FE8, and it's value (where the stack pointer point to) is 0xFFFFFFFF801064BC.

RIP=16
RSP=0xFFFFFFFF80529FE8
RBP=0xFFFFFFFF8052A000
RSP Point to=0xFFFFFFFF801064BC

[Octocontrabass]

That value is the return address. The call that jumps into nowhere is the "call *(%rax)" instruction immediately before it. So, the bad address is in RAX.

Without a more complete disassembly of that function, it's hard to say for sure, but it looks like RAX gets its value from the "mov (%rdi),%rax" instruction immediately before the call. So, RDI is most likely pointing to data that is either uninitialized or improperly initialized.

[bellezzasolo]

I don't see where you call global constructors? Calling Global Constructors

C++ doesn't require a lot of support code unless you want fancy stuff like exceptions and RTTI. But some initialisation is required. https://github.com/ChaiSoft/ChaiOS/blob ... as/cpp.cpp