Cross-compiler vs Visual Studio

[neon]

Note that unless you make some licensing deal with Microsoft, Visual Studio is a dead end if you ever consider going self-hosting (you may not want that today, but suddenly it seems possible and you want it).

Not necessarily a dead end (look at ReactOS for example.) Just not worth it in the long run; it is possible but the OS would have to be basically a Windows clone in order to support it.

[kutkloon7]

Thanks for the reactions, this stuff is good to know! I will certainly look into GCC and building a cross-compiler. I didn't to it immediately becuause I though VS would work practically the same. And I have to say, I have near zero experience with linux environments. Well, maybe it's time time to get some

I think I will set up gcc and cygwin to work from sublime text.

[OSwhatever]

Mentorgraphics have the old Codesourcery precompiled GCC toolchain if you want to download the binaries for an existing target.

http://www.mentor.com/embedded-software ... e-edition/

Might save you some time as compiling GCC is a lengthy process.

While GCC currently might be the best compiler for kernel work, I personally don't like how they manage different targets.

The keyword you see here is "you have to compile the cross compiler". Then for your OS, you have to compile GCC again for your OS despite it's the same code generator. For ARM, there is arm-none-eabi, arm-linux-elf a SymbianOS one and probably loads of other different operating system. All these are likely to use the same code generator but they just configured differently when it comes library support. I think this is absolutely ludicrous.

In practice you just need one compiler for a process target and then for different operating system, the compiler should choose the appropriate library, linker script and startup hooks. With LLVM I hope this stupid idea with GCC will stop and you just need one compiler for several processor targets as well as operating system targets. Unfortunately LLVM isn't really on the same maturity level as GCC.

Why don't you go and compile your GCC, 15 times for all your different needs........sounds fun?

[sortie]

Note that we can't really recommend downloading pre-compiled compilers from whatever odd links on the internet. They can't really be trusted and is a considerable security risk. Furthermore, don't be lazy. It's good experience knowing how to compile gcc and it makes you awesome ("I build my own compilers!"). It doesn't really take that long compiling GCC, especially compared to the many months spent building a basic operating system.

OSwhatever: I do occasionally build GCC 15 times on a good day. I like to think it makes my day awesome whenever I build gcc and more so when I do it repeatedly. Laziness will not be rewarded in our discipline.

Then for your OS, you have to compile GCC again for your OS despite it's the same code generator.

Uh, what? Are you saying it sucks that you have to cross-compile the compiler to run it on your OS? Well, you do!

[dozniak]

Mentorgraphics have the old Codesourcery precompiled GCC toolchain if you want to download the binaries for an existing target.

There's actually a load of links to precompiled gcc toolchains at the bottom of GCC Cross-Compiler wiki page. Compiled by your very own OSdev community members.

[OSwhatever]

OSwhatever: I do occasionally build GCC 15 times on a good day. I like to think it makes my day awesome whenever I build gcc and more so when I do it repeatedly. Laziness will not be rewarded in our discipline.

Uh, what? Are you saying it sucks that you have to cross-compile the compiler to run it on your OS? Well, you do!

You might find compiling GCC over and over again interesting but I find it a sorry state of computing which follows the sad traditions in many GNU projects. This is like Linux 10 years ago when you had to recompile the kernel just to add a driver.

I also obviously meant you shall only need to compile your cross compiler once for one host. If you mean you're going to compile GCC for using your own OS as host, then of course you need to compile it for that operating system.

[h0bby1]

OSwhatever: I do occasionally build GCC 15 times on a good day. I like to think it makes my day awesome whenever I build gcc and more so when I do it repeatedly. Laziness will not be rewarded in our discipline.

Uh, what? Are you saying it sucks that you have to cross-compile the compiler to run it on your OS? Well, you do!

You might find compiling GCC over and over again interesting but I find it a sorry state of computing which follows the sad traditions in many GNU projects. This is like Linux 10 years ago when you had to recompile the kernel just to add a driver.

I also obviously meant you shall only need to compile your cross compiler once for one host. If you mean you're going to compile GCC for using your own OS as host, then of course you need to compile it for that operating system.

It can depend on the policy if you see more creating specific tools to be used to develop the os, or if you see more creating your os in sort already existing tools can be used to develop it.

Regarding that compilers like gcc or visual studio are big projects, who evolve all the time, and are to be considered as industry standard, maybe the version of gcc you base your build on will be obsolete in 2 year, and then you'll have to check back all compatibilities all over again when you want to update to a new version of the compiler, so it might be just better not to rely too much on specific feature of a particular compiler build, but rather making code that can be compiled with as much different widely distributed compilers versions as possible.

But if you want to really exploit some feature of a particular build of a compiler, and that you do it on purpose with a clear design in mind of what specific feature you need in your compiler, and that you explicitly want to make the os development dependent on those compiler specific feature, it can be also a valid policy. Specially that gcc can be used on most platform that can be used for development.

[kutkloon7]

I decided to try linux mint in virtualbox, so I can try to set up a cross-compiler. I saw the guide on the wiki and will use that as a guide and/or pointer to google more information and tutorials. The information on the wiki is usually pretty good, but a bit brief for my taste.

I'm excited! Let's see how this all works out!

[kutkloon7]

EDIT: I suck at using google! I already found this thread when I tried again, now trying to fix it...
EDIT2: Fixed it by installing the texinfo package!

The information on the wiki is fine, actually!
Unfortunately, I got some errors while trying to build binutils (v2.23.2). The last lines that are shown after running the 'make' command (as suggested in the wiki):

make[3]: Leaving directory `/home/ruben/src/build-binutils/bfd/po'
make[3]: Entering directory `/home/ruben/src/build-binutils/bfd/po'
make[3]: Nothing to be done for `info'.
make[3]: Leaving directory `/home/ruben/src/build-binutils/bfd/po'
make[3]: Entering directory `/home/ruben/src/build-binutils/bfd'
make[3]: Nothing to be done for `info-am'.
make[3]: Leaving directory `/home/ruben/src/build-binutils/bfd'
make[2]: *** [info-recursive] Error 1
make[2]: Leaving directory `/home/ruben/src/build-binutils/bfd'
make[1]: *** [all-bfd] Error 2
make[1]: Leaving directory `/home/ruben/src/build-binutils'
make: *** [all] Error 2

I have binutils v2.23.2 and I try to compile v2.23.2 with gcc v4.7.3 (unfortunately, I can use the newest version v4.8.1). There is this table that you can use to see which version of GCC and binutils you can use, but GCC v4.7.3 is not listed there... (I'm also not really sure if the version of GCC listed there represents the GCC version you are trying to compile or the version you are using to compile... If the former is the case, the version of gcc shouldn't even matter now).
Sorry, I don't now what to do or try: I'm terribly inexperienced with linux systems, and I already tried google

[dozniak]

As you can already see your quoted output of make command does NOT include any useful information as to why it has failed.

Try actually reading the last part of the log until you find a line containing "error:" or something similar, it may explain you what to do next.

[kutkloon7]

Oh, I wasn't aware of that: I thought the 'error 1' and 'error 2' were the actual errors.
Anyway, I think I got a good build now. I built gcc version 4.7.3, because I didn't feel like bootstrapping to 4.8.1.

I will try to compile some code this week (I hope I have some time for it tonight), I'm curious about the results!

I have to say that I still don't feel like I understand all the headers in the object- and executable files. Compiling to a flat binary format seems much more efficient to me. I get that wouldn't allow any linking, but we don't need that for a kernel anyway, do we?

[sortie]

Loading statically linked ELF files is really simple. You just parse the program headers and look for LOAD entires. Couldn't be simpler. It's very much superior to "flat binary files", especially because the files allow fragmented memory (without lots of zeroes) and contain information where they should be loaded (unlike "flat binary files" where you have to know that somehow).

[h0bby1]

Oh, I wasn't aware of that: I thought the 'error 1' and 'error 2' were the actual errors.
Anyway, I think I got a good build now. I built gcc version 4.7.3, because I didn't feel like bootstrapping to 4.8.1.

I will try to compile some code this week (I hope I have some time for it tonight), I'm curious about the results!

I have to say that I still don't feel like I understand all the headers in the object- and executable files. Compiling to a flat binary format seems much more efficient to me. I get that wouldn't allow any linking, but we don't need that for a kernel anyway, do we?

You might want to have a way to call kernel routine latter on, but other mechanism than linking using existing exe format can be made, you could just have a table of function/symbol pointer at fixed location in the kernel image or using interupts or other way to make kernel call without having to link with it.

if you go for a micro/nano kernel approach, you might just want the kernel to set a few things and jump to C, and not having any routine in the kernel, or you can use other method to handle inter module links.

Flat binary doesn't allow uninitialized section either.

But in the absolute, you'll probably need an exe loader at some point. You can do you without, but to develop complex and easy to update inter module interface, it's much easier using shared library.

And loading simple elf or PE as mentionned is not that hard, for the most basic feature, either PE or elf, you just have to load the sections in the memory location specified in section headers, if you support paged memory, it's rather easy, but then the loader would lack support also for many feature of the format. Supporting relocation and symbol import/export might be a bit more difficult.

[kutkloon7]

Thanks for the replies! I think it starts to make sense now.
You guys have been very helpful!

[kutkloon7]

Phew, compiling in GCC is hard, I can't find a tutorial which is aimed at what I want. Right now, the simplest choice seems to be compiling in C (not C++). In Brokenthorns series, he used a lot of header files to replace some important parts of the standard library (the null definition, code for variable initializers, etc.).

I guess I need to add some asm code to set up the stack and set the data segment correctly anyway, so I will look into that (and the horrible AT&T syntax) tomorrow.
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++?)