C++ Bare Bones kmain.cpp Error

[twixthehero]

Hello! -

I recently started on the Bare Bones tutorial for C++ on Ubuntu.

Assembling loader.s with NASM went perfectly fine, while I get this error trying to assemble kmain.cpp:

twixthehero@mini12:~/os$ gcc -o kmain.o -c kmain.cpp
kmain.cpp:1:19: error: cstdint: No such file or directory
kmain.cpp: In function ‘void kmain()’:
kmain.cpp:5: error: expected unqualified-id before string constant
kmain.cpp:6: error: expected unqualified-id before string constant
kmain.cpp:8: error: ‘magic’ was not declared in this scope

kmain.cpp

Code: Select all

#include <cstdint>

extern "C" void kmain(void)
{
   extern "C" uint32_t magic;
   extern "C" void *mbd;

   if (magic != 0x2BADB002)
   {
      /* Something went not according to specs. Print an error */
      /* message and halt, but do *not* rely on the multiboot */
      /* data structure. */
   }

   //char * boot_loader_name = (char *) ((long *)mbd)[16];

   /* Print a letter to screen to see everything is working: */
   unsigned char *videoram = (unsigned char *)0xb8000;
   videoram[0] = 65; /* character 'A' */
   videoram[1] = 0x07; /* light grey (7) on black (0). */
}

Does anyone know what is wrong?

[iansjack]

The errors tell you exactly what is wrong. For starters, the compiler cannot find the header file that is included which probably explains the further errors. Almost certainly this is because you are using "gcc" rather than "g++" to compile the file (although I can't be bothered to check that).

Try following the tutorial, using the correct commands, and - preferably - building a cross-compiler first.

[sortie]

You really should build your kernel with a cross-compiler (see our wiki), it'll be better in the longer run. <cstdint> is part of the C++ runtime if I recall correctly, it may not be available directly with a freestanding C++ cross-compiler. In that case, it's sibling <stdint.h> from C would work instead.

Your cross-compiler will ship with various freestanding headers that can be used even for kernels, you can find them in $GCC_CROSS_COMPILER_DIR/lib/gcc/$TARGET_PLATFORM/$GCC_VERSION/include. Have a look, there are a few very useful things in here.

If you are using the GNU toolchain (gcc, g++, ld, objdump (binutils), ...) then I recommend using the GNU assembler (simply 'as' from the command line) instead of NASM, because then the compiler, objdump and assembler all have the same assembly syntax - otherwise NASM would use one syntax and the compiler and disassembler would use another.

Also note that you are defining these variables _inside the kmain_ function. That will probably not do what you think (and your compiler isn't accepting it, hence one of the errors). Make them globals instead!

[iansjack]

To be fair, the OP used the exact code from the tutorial. If that code doesn't compile, using the tools and instructions given in the tutorial, then perhaps the Wiki page needs to be updated.

[cxzuk]

I believe the errors are deliberate, to make sure the programmer has certain basic skills.

[iansjack]

If so then I consider that counterproductive. The result is, as here, more noise in the system.

I'd prefer to reserve judgement until the OP has followed the tutorial instructions correctly.

[cxzuk]

I believe the argument is that the wiki should not provide a copy&paste operating system, but provide descriptions of theories, designs and structures.

Whether thats a good goal for the wiki, or if the errorsome code hinders learning of these? Im not sure.

[cxzuk]

As a side note; All external tutorials are(/should) be fairly error free, or the bugs of them listed.

[iansjack]

Lack of a complete solution I would applaud. Provide enough, accurate, information to allow a tyro to proceed but don't spoonfeed them. But I can't agree with introducing deliberate errors unless it is clearly stated that that is the case and the point of the exercise is to detect and correct such errors.

[cxzuk]

I agree; If it is deliberate, then perhaps transparency is the right way to go.

[twixthehero]

Thanks for the replies!

The errors tell you exactly what is wrong. For starters, the compiler cannot find the header file that is included which probably explains the further errors. Almost certainly this is because you are using "gcc" rather than "g++" to compile the file (although I can't be bothered to check that).

Try following the tutorial, using the correct commands, and - preferably - building a cross-compiler first.

I want to point out that I tried "g++" AND "gcc" and both got me the exact same result. The code in the tutorial uses

Code: Select all

#include <cstdlib>

which doesn't make any sense. Literally five line up, it says "As soon as you do #include < you've made a mistake. Welcome to kernel land!" Why would I need to use this include statement when it says I shouldn't?

You really should build your kernel with a cross-compiler (see our wiki), it'll be better in the longer run. <cstdint> is part of the C++ runtime if I recall correctly, it may not be available directly with a freestanding C++ cross-compiler. In that case, it's sibling <stdint.h> from C would work instead.

But isn't using <stdint.h> the C header, while the tutorial is for C++?

Your cross-compiler will ship with various freestanding headers that can be used even for kernels, you can find them in $GCC_CROSS_COMPILER_DIR/lib/gcc/$TARGET_PLATFORM/$GCC_VERSION/include. Have a look, there are a few very useful things in here.

If you are using the GNU toolchain (gcc, g++, ld, objdump (binutils), ...) then I recommend using the GNU assembler (simply 'as' from the command line) instead of NASM, because then the compiler, objdump and assembler all have the same assembly syntax - otherwise NASM would use one syntax and the compiler and disassembler would use another.

Also note that you are defining these variables _inside the kmain_ function. That will probably not do what you think (and your compiler isn't accepting it, hence one of the errors). Make them globals instead!

I will make the change to using the GNU assembler. I'm not too informed about programming in assembly, so I will take your advice. That logically makes sense that you wouldn't want different syntaxes.

[twixthehero]

Switching to GNU assembler and using the code on the wiki gives an error on the line ".lcomm stack, STACKSIZE, 32" where the second comma starts the unrecognized area. I removed the ", 32" and it assembled just fine (although I'm not sure what this affects).

I built the cross-compiler, and using it to compile still runs into the same error as in the original post.

[Griwes]

The code in the tutorial uses

Code: Select all

#include <cstdlib>

which doesn't make any sense. Literally five line up, it says "As soon as you do #include < you've made a mistake. Welcome to kernel land!" Why would I need to use this include statement when it says I shouldn't?

You should read more than just the tutorial to really know what you are doing. For one, you surely missed this (<- link; not really visible in default theme, sadly):

A "freestanding" environment needs to provide only a subset of the C library: float.h, iso646.h, limits.h, stdarg.h, stdbool.h, stddef.h, and stdint.h (as of C99). All of these consist of typedef s and #define s "only", so you can implement them without a single .c file in sight.

Same goes for <c****> variants of those from C++.

You really should build your kernel with a cross-compiler (see our wiki), it'll be better in the longer run. <cstdint> is part of the C++ runtime if I recall correctly, it may not be available directly with a freestanding C++ cross-compiler. In that case, it's sibling <stdint.h> from C would work instead.

But isn't using <stdint.h> the C header, while the tutorial is for C++?

<cstdint> is the same thing as <stdint.h>, it just puts things in std:: instead (or besides) ::, so it's definitely not part of runtime (what would be runtime in definitions of int types?).

As for C vs C++ header here: if you are using C++11, then you have <cstdint> at your disposal. If you aren't using it (but you definitely *should*), you probably only have <stdint.h> from C99 (IIRC, most of <cstdint>s do check whether you're in C++11 mode).

[twixthehero]

The code in the tutorial uses

Code: Select all

#include <cstdlib>

which doesn't make any sense. Literally five line up, it says "As soon as you do #include < you've made a mistake. Welcome to kernel land!" Why would I need to use this include statement when it says I shouldn't?

You should read more than just the tutorial to really know what you are doing. For one, you surely missed this (<- link; not really visible in default theme, sadly):

A "freestanding" environment needs to provide only a subset of the C library: float.h, iso646.h, limits.h, stdarg.h, stdbool.h, stddef.h, and stdint.h (as of C99). All of these consist of typedef s and #define s "only", so you can implement them without a single .c file in sight.

Same goes for <c****> variants of those from C++.

You really should build your kernel with a cross-compiler (see our wiki), it'll be better in the longer run. <cstdint> is part of the C++ runtime if I recall correctly, it may not be available directly with a freestanding C++ cross-compiler. In that case, it's sibling <stdint.h> from C would work instead.

But isn't using <stdint.h> the C header, while the tutorial is for C++?

<cstdint> is the same thing as <stdint.h>, it just puts things in std:: instead (or besides) ::, so it's definitely not part of runtime (what would be runtime in definitions of int types?).

As for C vs C++ header here: if you are using C++11, then you have <cstdint> at your disposal. If you aren't using it (but you definitely *should*), you probably only have <stdint.h> from C99 (IIRC, most of <cstdint>s do check whether you're in C++11 mode).

Thanks for your reply. I followed your link, and I realized that it was from Step 2 of the GCC Cross-compiler, which, somehow I had stopped at step 1's "usage" (Silly me! )

I'll finish that and see where it takes me.

[Love4Boobies]

Literally five line up, it says "As soon as you do #include < you've made a mistake. Welcome to kernel land!" Why would I need to use this include statement when it says I shouldn't?

Thanks for pointing this out. The C version of this tutorial had the same error. When I removed it, I didn't think to check the C++ version as well.