Is C++ virtual function unavailable in kernel programming?

RichardC1ay · **Joined:** Sat Jan 15, 2022 9:33 pm **Posts:** 3

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

Code:

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:

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:

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:

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:

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:

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:

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 · **Posted:** Mon Mar 27, 2023 9:17 am

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 · **Joined:** Mon Mar 25, 2013 7:01 pm **Posts:** 4680

RichardC1ay wrote:

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 · **Joined:** Sat Jan 15, 2022 9:33 pm **Posts:** 3

Octocontrabass wrote:

RichardC1ay wrote:

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 · **Joined:** Mon Mar 25, 2013 7:01 pm **Posts:** 4680

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 · **Joined:** Sun Feb 20, 2011 2:01 pm **Posts:** 110

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/8dd9413e8d7229724267bdcc9fbfb5770d6cc412/Kcstdbas/cpp.cpp

OSDev.org

Is C++ virtual function unavailable in kernel programming?

Who is online