gcc does not compile my class......

[bsunisol]

hi,
i'm using djgpp to compile my os.
i want to code everything with classes.
but gcc doesn't compile one of these classes.

here's the code:

Code: Select all

#ifndef _VIDEO_H
#define _VIDEO_H

#include "asm.h"


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 );

	private:
		void scrollup() ;
		void setcursor( unsigned x, unsigned y );

		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'

does anyone know what's wrong

thanks
bsunisol

[frank]

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.

[ehird]

Also, use g++ to compile c++ files, not gcc.

[bsunisol]

ok. now its compiling everything.

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 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'

the ld.txt:

Code: Select all

OUTPUT_FORMAT("binary")
INPUT( BINARIES\tmp\osloader\OSLDRS.obj
       BINARIES\tmp\osloader\OSLDR32.obj
       BINARIES\tmp\osloader\modules\asm.obj
       BINARIES\tmp\osloader\modules\fdd.obj
       BINARIES\tmp\osloader\modules\isr.obj
       BINARIES\tmp\osloader\modules\video.obj
       BINARIES\tmp\osloader\OSLDRC.obj )
ENTRY(start)
SECTIONS
{
  .text  0x0700 : {
    code = .; _code = .; __code = .;
    *(.text)
    . = ALIGN(1);
  }
  .data  : {
    __CTOR_LIST__ = .; LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2) *(.ctors) LONG(0) __CTOR_END__ = .; 
    __DTOR_LIST__ = .; LONG((__DTOR_END__ - __DTOR_LIST__) / 4 - 2) *(.dtors) LONG(0) __DTOR_END__ = .; 
    data = .; _data = .; __data = .;
    *(.data)
    . = ALIGN(1);
  }
  .bss  :
  {
    bss = .; _bss = .; __bss = .;
    *(.bss)
    . = ALIGN(1);
  }
  .rodata  : {
    *(.rodata)
    . = ALIGN(1);
  }
  end = .; _end = .; __end = .;
}

but i have all defined with extern or global.
if necessary i'll post the source code.

thanks
bsunisol

[ehird]

Mixing C and C++ doesn't work. You have to compile everything with g++ if you want to avoid hell.

[Candy]

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.

[mystran]

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..

[bsunisol]

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'

[mystran]

___gxx_personality_v0 is supposedly something defined in the C++ library G++ uses. You should be compiling with something like the following flags:

Code: Select all

-nostdinc -nostdlib -fno-builtin -ffreestanding -fno-common -fno-rtti -fno-exceptions

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.

[Candy]

___gxx_personality_v0 is supposedly something defined in the C++ library G++ uses. You should be compiling with something like the following flags:

Code: Select all

-nostdinc -nostdlib -fno-builtin -ffreestanding -fno-common -fno-rtti -fno-exceptions

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.

[mystran]

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..

[Candy]

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 .

The ABI: http://www.codesourcery.com/cxx-abi/abi.html#mangling . This one matches the GCC mangling pretty closely if not perfectly.