OSDev.org

Hello,

Compiling in GCC is about the same difficulty as that of CL used by MSVC. Information on using GCC for OS development however is more widely available then that of CL; please see Wiki:C++ for information on using C++ in GCC and VS. It also provides example code for executing static initializer functions. Note that if using C, this is not needed.

Please note that GCC does have some support for Intel syntax (not necessarily the same syntax used in CL.) Some prefer the AT&T syntax however as it can be better optimized. Alternatively, don't use inline assembly language. That is, write the startup code in a different assembler (like NASM) and link it (if interested, this is the method we use.)

Excuse me, I should have checked out that wikipage on C++ before posting that last one (and I would have if I thought of it). I did a google session a few hours ago, but I couldn't find out if I had to write code to handle static global initializers or not. Probably due to my poor knowledge of the terminology. Also, I had no idea that GCC could handle intel syntax! I really start to respect the programmers who worked on GCC.
Compiling with NASM and then linking it in seems fine too, but I want to keep things as simple as possible for now, and I haven't really learnt about linking yet. Maybe something for later.

Anyway, thanks for your reply! You're very friendly towards newbies

I've carefully documented how to call C++ global constructors in a kernel at http://wiki.osdev.org/Calling_Global_Constructors. This might even make even to do in C code because __attribute__((constructor)) exists, and the compiler could theoretically convert C global variables into global variable code.

The recommended GCC freestanding usage is shown in the examples at http://wiki.osdev.org/Bare_Bones. Or, if you mean the gcc switches in general: You'll simply have to learn them. It's not that bad and it's fairly consistent between Unix compilers.

Awesome! I decided to use C for now, as it's a bit simpler for now. I compiled the example kernel succesfully, but my naive loader is just a little too simple to run it sucessfully. I just find out where the entry point is in RAM, and then jump to that. Unfortunately, this messes up the pointers (in this example the pointer that should point to the "Hello, kernel World!\n"-string gets shifted by 1000 bytes, which makes it point into the void, so there is no text being displayed). I was able to fix this by hand, but I need to start writing an ELF loader anyway, I guess.

So, all in all this works better than expected! Although it was easier to use an PE file at this stage, I have no doubt that using ELF and GCC has advantages compared to Visual Studio.

kutkloon7 wrote:.
There is one thing that especially confuses me: in the Brokenthorn series, there is code explicitly added to load initializers for the variables. In the comments, there is stated that this is the MSVC++ runtime and this is highly specific to microsoft visual studio. Do I need something similar for compling c with gcc? (or even for compiling c++?)

gcc has something similar, with visual studio, the crt entry point is maincrtStartup for console subsystem and winmaincrtstartup for windows subsystem,i guess the two have different type of runtime, windows appliction are not supposed to use stdin/stdout at all, which i think is part of the thing that the runtime intialize, with gcc it's __libc_start_main () , the code for those functions is avaible in both case, with visual studio you get the source in the visual studio folder, and gcc it's part of libgcc, but in all cases it's system specific code, that can have to deal with initializing the heap, process/threading , and cleanly exiting process/thread and clean up memory, and also yes static initializers and stuff like that , in any case it's both specific to the compiler's runtime and the target system.

It's also used for C program, even if the runtime is much simpler in C , and you can easily avoid the whole compiler runtime if you just don't use any function of the C Library at all, there are only very few things of the runtime that are really needed for C program if they don't use functions of the C Library.

C++ can be much harder to debug, it's the main problem imo with c++, with C when there are memory leak, or memory overwrite, you can generally easily figue it out, with c++, the way memory can be managed when class inheritence or virtual functions are involved can make it hard to figure if memory get overwritten, or if class pointer are messed with, it's why compiler runtime and using stl or a c++ environment is generally more common, but bare c++ without any runtime library behind can become hard to debug, and there are many things that all compiler might handle differently, even the thiscall is not entierly the same across compilers, normally the class pointer is supposed to be stored in a register, but if you enable optimization or other, different compilers might handle the call differently and create incompatibilities.

I was confusing the compiler runtime library with parts of the language that are defined in header files (not in the compiler).

Things as booleans, for example. They are part of the C-language, but they are specified in - *peeks at kernel.c* - stdbool.h.
It is pretty confusing, as some parts that you always considered to be part of the language (and thus, handled by the compiler) are actually handled by object and header files. For example, looking at .../cross/lib/gcc/i386-elf/4.7.3 (I came across thar while trying to find stdbool.h), I see crtbegin.o and crtend. I have no idea if they are used by gcc. I certainly don't link against them, but maybe gcc does this internally? I think this is the code that calls global constructors and destructors (is this only used in c++, or are the global initializer functions just called constructors?). Weird: in the dissassembly of crtbegin.o I see symbols about destructors, and in crtend.o about constructors, I would expect them the other way around...

Questions, questions, questions. Well, at least I got it all working!
I want to stress again how helpful you guys have been!

I have documented the object files crtbegin.o and crtend.o at http://wiki.osdev.org/Calling_Global_Constructors. Basically, they are magic files that you link in before and after everything else, and they do whatever magic to figure out the constructor and destructor table. You then roll your own crti.o and crtn.o (in a kernel, or in your personal libc) and wrap them around everything else (including crtbegin.o and crtend.o) and use some tricks to create _init and _fini functions. You can then simply call the _init function when you feel confident you want the global constructors initialized. You can use __attribute__((constructor)) and __attribute__((destructor)) on C functions if you want them called at program initialization and destruction time. Note that these object files are kinda funky and you won't learn much from disassembling them.

Great, thanks! I will read it

kutkloon7 wrote:I was confusing the compiler runtime library with parts of the language that are defined in header files (not in the compiler).

Things as booleans, for example. They are part of the C-language, but they are specified in - *peeks at kernel.c* - stdbool.h.
It is pretty confusing, as some parts that you always considered to be part of the language (and thus, handled by the compiler) are actually handled by object and header files. For example, looking at .../cross/lib/gcc/i386-elf/4.7.3 (I came across thar while trying to find stdbool.h), I see crtbegin.o and crtend. I have no idea if they are used by gcc. I certainly don't link against them, but maybe gcc does this internally? I think this is the code that calls global constructors and destructors (is this only used in c++, or are the global initializer functions just called constructors?). Weird: in the dissassembly of crtbegin.o I see symbols about destructors, and in crtend.o about constructors, I would expect them the other way around...

Questions, questions, questions. Well, at least I got it all working!
I want to stress again how helpful you guys have been!

If you are used to visual studio, also need to keep in mind there are many things that visual studio is supposed to do with project wizzards, when you create a project in visual studio, it ask many things about the type of project, if it's a dll, a static library, an executable, if it's a console or windows program, if it use MFC or ATL , and there are many things visual studio then assume regarding the runtime to use, and general project setting, for it to fit it all together, but it's not always very well documented on the low level side, and it's also very specific to the windows system, and the platform sdk visual studio use, before vc 2005 it could become really ugly once you wanted to do something without using wizzards, as well to generate project setting, but also some code for class definition, if working with MFC or ATL.

Linux doesn't really have such a system, and gcc is much more structured and can allow for great customization of any part of the process of compilation and of the system dependent application context, with visual studio normally you are supposed to use project wizzards to setup the project, and it will assume a particular configuration from the project type, and there is no project type that really fit what you need to develop an OS, and most likely the runtime will make some problem if you run it outside of windows, so you need to setup the project manually and deal with all the visual studio options on your own, and you more likely want visual studio to assume as little as possible about the environment in which the exe will be run.

But C always came with the C library, and C programers always assumed a program in C can use those functions, and that a C build environment would be able to compile exe that use the C library, even in time of Turbo C in dos there was already the C Library headers, which already implied a whole framework of execution for programs with the stdin/stdout, that is not entierly part of the C language definition but that most application developed in C would use and depend on, and a an operating system who want to run C application must provide an implementation of the C Library, and C compiler must also provide some specific code to implement this application framework for a particular system.

But it's more to be seen as an application context model, that require system specific implementation, that most application made in C use, rather than being part of the language itself, it's just that application made in C always relied on some system specific layer of software , and C building environment/compilers always made in sort to make it as transparent as possible, and this standard set of system specific functions as well as the application model as been defined very early and all compilers/C building tools used this same standard.

Even now visual studio can handle even high level system specific thing in sort that the system specific layer is transparent to the developers, when you use wizzard to setup ATL or MFC class for example to be used as COM components, the wizzard can handle many things, and on the functional level of the IDE for people who work entierly under visual studio, ATL/MFC/DirectX could be also considered as part of the language as it's under the scope of type and components that the building tool know of internally.It can allow to setup application context specific to windows that are very complex very easily using visual studio.

h0bby1 wrote:If you are used to visual studio, also need to keep in mind there are many things that visual studio is supposed to do with project wizzards, when you create a project in visual studio, it ask many things about the type of project, if it's a dll, a static library, an executable, if it's a console or windows program, if it use MFC or ATL , and there are many things visual studio then assume regarding the runtime to use, and general project setting, for it to fit it all together, but it's not always very well documented on the low level side, and it's also very specific to the windows system, and the platform sdk visual studio use, before vc 2005 it could become really ugly once you wanted to do something without using wizzards, as well to generate project setting, but also some code for class definition, if working with MFC or ATL.

Particularly;

there are many things that visual studio is supposed to do with project wizzards

The only thing I can think of is when you create a project, and the "deploy" wizard. In the cast of creating a project - Visual Studio's "wizards" are simply just generating you a template, no different to starting from a template in KDevelop, for example.

I always use "Empty Project" and make sure "generate files" is not checked. The next thing I do is create a "main.cpp", and configure my include/library/build directories. Everything else is writing code and debugging. No need to touch a wizard. What wizards are you referring to?

I agree - I never use MFC or ATL - it's very ugly!

MessiahAndrw wrote:

h0bby1 wrote:If you are used to visual studio, also need to keep in mind there are many things that visual studio is supposed to do with project wizzards, when you create a project in visual studio, it ask many things about the type of project, if it's a dll, a static library, an executable, if it's a console or windows program, if it use MFC or ATL , and there are many things visual studio then assume regarding the runtime to use, and general project setting, for it to fit it all together, but it's not always very well documented on the low level side, and it's also very specific to the windows system, and the platform sdk visual studio use, before vc 2005 it could become really ugly once you wanted to do something without using wizzards, as well to generate project setting, but also some code for class definition, if working with MFC or ATL.

Particularly;

there are many things that visual studio is supposed to do with project wizzards

The only thing I can think of is when you create a project, and the "deploy" wizard. In the cast of creating a project - Visual Studio's "wizards" are simply just generating you a template, no different to starting from a template in KDevelop, for example.

I always use "Empty Project" and make sure "generate files" is not checked. The next thing I do is create a "main.cpp", and configure my include/library/build directories. Everything else is writing code and debugging. No need to touch a wizard. What wizards are you referring to?

I agree - I never use MFC or ATL - it's very ugly!

wizzard can be used to make mfc or atl class, handle events, and handle also class hierarchy and events in atl projects, and the template generated involve selecting things also regarding how and which runtime is linked, even the preprocessor definition selected in different configuration will impact the way things are compiled if you use the platform sdk and the runtime.

wizzard can be used to add atl/mfc class and handle their hierarchy and how they are supposed to be compiled and how they are supposed to be run on which platform. you get that in project->add class, and there are some windows to manipulate idl files and interface definition and the definition of the global atl components.

creating empty project can be fine as well it's what i do also for osdev, but for more complex project involving mfc or atl it can be also good to use the wizzard, mfc often require some macro to declared class or declare some things, and can also potentially involve dealing with the runtime for multi threading or how shared memory works, and to handle state of the modules.

h0bby1 wrote:wizzard can be used to

wizzard can be used to

Wizards can also be spelled properly.

dozniak wrote:

h0bby1 wrote:wizzard can be used to

wizzard can be used to

Wizards can also be spelled properly.

thanks for this invaluable contribution .

h0bby1 wrote:thanks for this invaluable contribution .

Start sentences with a capital letter. There should be no space between the word and the punctuation marks like comma or semicolon.

dozniak wrote:

h0bby1 wrote:thanks for this invaluable contribution .

Start sentences with a capital letter. There should be no space between the word and the punctuation marks like comma or semicolon.

Please don't use redundant line breaks.