Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
typedef enum _Color { BLACK, // background and text BLUE, GREEN, CYAN, RED, MAGENTA, BROWN, WHITE, DARKGRAY,
BRIGHTBLUE, // only text BRIGHTGREEN, BRIGHTCYAN, PINK, BRIGHTMAGENTA, YELLOW, BRIGHTWHITE } Color;
class Video { // Video class public: Video(); ~Video();
void clear(); void write( char *cp ); void put( char c ); void gotoxy( unsigned x, unsigned y );
void SetColour( Color Text, Color Back, bool blink ); unsigned char GetBackColor(); unsigned char GetTextColor(); void SetBackColor( Color col ); void SetTextColor( Color col );
unsigned short* videomem; //pointer to video memory unsigned short crtc_mem; unsigned int ypos; //offset, used like a y cord unsigned int xpos; //position, used like x cord unsigned int scrHeight; unsigned int scrWidth; unsigned char color; //Text colours unsigned char text; unsigned char back; };
#endif
and the error-code is:
video.h:27: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Video'
Are you naming the source file with the class in it .c or .cpp. Remember that in C you cannot have classes so you have to remember to give your files the extension .cpp. Also check in your headers to make sure that you have semicolons everywhere that they should be.
but the linker (ld) says the labels/functions are unknown......
BINARIES\tmp\osloader\OSLDR32.obj:BINARIES\tmp\osloader\OSLDR32.obj:(.text+0x1): undefined reference to `__support_start' BINARIES\tmp\osloader\OSLDR32.obj:BINARIES\tmp\osloader\OSLDR32.obj:(.text+0xb): undefined reference to `__support_end' BINARIES\tmp\osloader\OSLDR32.obj:BINARIES\tmp\osloader\OSLDR32.obj:(.text+0x123): undefined reference to `_fault_handler' BINARIES\tmp\osloader\OSLDRC.obj: In function `LoadIDT()': SRC\osloader/OSLDRC.cpp:73: undefined reference to `__Z4isr0v' SRC\osloader/OSLDRC.cpp:74: undefined reference to `__Z4isr1v' SRC\osloader/OSLDRC.cpp:75: undefined reference to `__Z4isr2v' SRC\osloader/OSLDRC.cpp:76: undefined reference to `__Z4isr3v' SRC\osloader/OSLDRC.cpp:77: undefined reference to `__Z4isr4v' SRC\osloader/OSLDRC.cpp:78: undefined reference to `__Z4isr5v' SRC\osloader/OSLDRC.cpp:79: undefined reference to `__Z4isr6v' SRC\osloader/OSLDRC.cpp:80: undefined reference to `__Z4isr7v' SRC\osloader/OSLDRC.cpp:81: undefined reference to `__Z4isr8v' SRC\osloader/OSLDRC.cpp:82: undefined reference to `__Z4isr9v' SRC\osloader/OSLDRC.cpp:83: undefined reference to `__Z5isr10v' SRC\osloader/OSLDRC.cpp:84: undefined reference to `__Z5isr11v' SRC\osloader/OSLDRC.cpp:85: undefined reference to `__Z5isr12v' SRC\osloader/OSLDRC.cpp:86: undefined reference to `__Z5isr13v' SRC\osloader/OSLDRC.cpp:87: undefined reference to `__Z5isr14v' SRC\osloader/OSLDRC.cpp:88: undefined reference to `__Z5isr15v' SRC\osloader/OSLDRC.cpp:89: undefined reference to `__Z5isr16v' SRC\osloader/OSLDRC.cpp:90: undefined reference to `__Z5isr17v' SRC\osloader/OSLDRC.cpp:91: undefined reference to `__Z5isr18v' SRC\osloader/OSLDRC.cpp:92: undefined reference to `__Z5isr19v' SRC\osloader/OSLDRC.cpp:93: undefined reference to `__Z5isr20v' SRC\osloader/OSLDRC.cpp:94: undefined reference to `__Z5isr21v' SRC\osloader/OSLDRC.cpp:95: undefined reference to `__Z5isr22v' SRC\osloader/OSLDRC.cpp:96: undefined reference to `__Z5isr23v' SRC\osloader/OSLDRC.cpp:97: undefined reference to `__Z5isr24v' SRC\osloader/OSLDRC.cpp:98: undefined reference to `__Z5isr25v' SRC\osloader/OSLDRC.cpp:99: undefined reference to `__Z5isr26v' SRC\osloader/OSLDRC.cpp:100: undefined reference to `__Z5isr27v' SRC\osloader/OSLDRC.cpp:101: undefined reference to `__Z5isr28v' SRC\osloader/OSLDRC.cpp:102: undefined reference to `__Z5isr29v' SRC\osloader/OSLDRC.cpp:103: undefined reference to `__Z5isr30v' SRC\osloader/OSLDRC.cpp:104: undefined reference to `__Z5isr31v' BINARIES\tmp\osloader\OSLDRS.obj:OSLDRS.cpp:(.eh_frame+0x11): undefined reference to `___gxx_personality_v0' BINARIES\tmp\osloader\modules\fdd.obj:fdd.cpp:(.eh_frame+0x11): undefined reference to `___gxx_personality_v0' BINARIES\tmp\osloader\modules\video.obj:video.cpp:(.eh_frame+0x11): undefined reference to `___gxx_personality_v0' BINARIES\tmp\osloader\OSLDRC.obj:OSLDRC.cpp:(.eh_frame+0x11): undefined reference to `___gxx_personality_v0'
ehird wrote:Mixing C and C++ doesn't work. You have to compile everything with g++ if you want to avoid hell.
There are worse things than c++ name mangling. Hell doesn't even come close.
You need to either compile stuff with C++ name mangling (what you're doing now, but for only half the project), tell C++ which functions not to mangle (by putting them in an extern "C" {} block) or not mangle anything (which screws up c++ so badly you can barely use it). Either tell your assembler the mangled names or tell C++ not to mangle them.
ehird wrote:Mixing C and C++ doesn't work. You have to compile everything with g++ if you want to avoid hell.
There are worse things than c++ name mangling. Hell doesn't even come close.
You need to either compile stuff with C++ name mangling (what you're doing now, but for only half the project), tell C++ which functions not to mangle (by putting them in an extern "C" {} block) or not mangle anything (which screws up c++ so badly you can barely use it). Either tell your assembler the mangled names or tell C++ not to mangle them.
extern "C" is the only good way to deal with this.
I'd be much more worried about "__gxx_personality_v0" which is obviously compiler specific stuff that needs to be solved somehow..
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
ok the references are fixed.
but there are still references i've never created
BINARIES\tmp\osloader\OSLDRS.obj:OSLDRS.cpp:(.eh_frame+0x11): undefined reference to `___gxx_personality_v0' BINARIES\tmp\osloader\modules\fdd.obj:fdd.cpp:(.eh_frame+0x11): undefined reference to `___gxx_personality_v0' BINARIES\tmp\osloader\modules\video.obj:video.cpp:(.eh_frame+0x11): undefined reference to `___gxx_personality_v0' BINARIES\tmp\osloader\OSLDRC.obj:OSLDRC.cpp:(.eh_frame+0x11): undefined reference to `___gxx_personality_v0'
If you are using then, and you still get the error, then you are trying to do something that triggers inclusion of references to library routines, and you either need to stop using those features, or implement the relevant library support yourself.
Note that I've not tried to support C++ in kernel, so I might have forgotten some flag. Those are the flags I use for C, plus -fno-rtti and -fno-exceptions to tell G++ to compile without those features of the language (both need library support).
At least the old version of our Wiki had some information on how to support various features yourself, but IMHO you should get the basic kernel working (at least to the point that it boots) first, before you start adding those.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
mystran wrote:___gxx_personality_v0 is supposedly something defined in the C++ library G++ uses. You should be compiling with something like the following flags:
If you are using then, and you still get the error, then you are trying to do something that triggers inclusion of references to library routines, and you either need to stop using those features, or implement the relevant library support yourself.
It's the -fno-exceptions flag. The personality function you miss tells the stack unwinding procedure how to unwind the stack (apparently). Since you don't have exceptions let alone unwind a stack, you don't need it (but you need to tell that explicitly).
If you standardise your project on a certain ABI, you can mangle all the names in ASM and get that working easily. I really like the gnu gcc name mangling, so I've fixed myself to that one. You can even make two files, one in pure asm, one in pure C++, that together form the implementation of one class.
Isn't there actually some attempt to standardize the mangling, at least on certain architectures, so that you should be able to get GCC and (say) VC++ to talk together nowadays?
Not sure though, could be I'm simply dreaming..
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
mystran wrote:Isn't there actually some attempt to standardize the mangling, at least on certain architectures, so that you should be able to get GCC and (say) VC++ to talk together nowadays?
Not sure though, could be I'm simply dreaming..
Guess why I picked that particular mangling? It's in the IA-64 ABI as predefined standard, which is also used as the x86_64 ABI (so yes, there too) and recommended for IA-32. I'm going to bet this'll be the thing they'll use the next, uh, 10-20 years? If I have to remake this when I'm 43 that's ok .