OSDev.org

drax wrote:Thank you everyone, I didn't expect to get as many answers!

Almamu wrote: change _k_main to k_main, it should fix the error, on GCC seems to not be needed the first underscore for calling C functions from ASM...

combined with:

-m32 wrote: Change To:
drax@debian:~/Desktop/basic_kernel$ nasm -f elf kernel_start.asm -o ks.o
drax@debian:~/Desktop/basic_kernel$ gcc -c kernel.c -o kernel.o -m32
drax@debian:~/Desktop/basic_kernel$ ld -T link.ld -o kernel.bin ks.o kernel.o -melf_i386

...Compiles without any error at all, but the code in kernel.c never runs. To test it here's what I've done in the code:
Print a character on the screen with INT 10, then call k_main, then print an other character with INT 10.
Result: the first character gets printed and then the system hangs.

Anyway I'll go with the cross-compiler idea since it seems to be the right thing to do!
Thanks for your help.

Why not print it to vidmem and not with int 10 ?

JackScott wrote:Building a cross compiler requires exactly one thing: the ability to follow instructions exactly. If you can't do that, you are unlikely to get anywhere in OSDev, or indeed life.

Solar wrote:That's an attitude that won't get you far in OS development, or any serious development work. Good software engineering is driven by a strong desire to "get it right" (as opposed to "just make it work"). It's the litmus test of the good vs. the mediocre developer.

Wow, everyone on this forum just loves thinly veiled insults eh? So, because someone doesn't use their own custom compiled cross-compiler, they're an idiot? Or a 'mediocre' programmer, or no good at life? Get off your high-horses.

Suggesting that someone who is new at something spend hours trying to figure out how to compile a cross-compiler just to get a tiny kernel to run is completely absurd. In fact, a cross-compiler is completely unnecessary when your target hardware is the same as your development platform!

-m32 wrote:In fact, a cross-compiler is completely unnecessary when your target hardware is the same as your development platform!

That point has been discussed to death.

Note that when compiling your compiler itself, you pass a triple of words as a target. One is the processor architecture, the second is the system architecture and the third is the operating system. If you want your kernel to be a Windows PE file with all its quirks & anomalies, please do continue. If you want it to be a Linux ELF, use your Linux compiler.

If you want your kernel to be targeted to your OS, use your own compiler.

There's also the issue of "works for me" if people can't get the exact same compiler as you do and then can't reproduce your problems. There are differences between versions and the 4.3.0 from Ubuntu versus the 4.3.0 from Redhat.

Nobody's on high horses. We've just been hit by the same damn issue for the past 8-10 years and would *please* like to be done with it. So when you do start developing a kernel and want to have a working start, take at least a week for it and make a crosscompiler - for which you only need the ability to download and copy/paste instructions - to avoid half a dozen "bugs" we are tired of answering questions about.

You wouldn't start building a house with another house's foundation. Stop building operating systems with tools that are just not fit.

(Candy beat me to it, but I'll post my take anyway.)

You consistently ignore that the very first mention of a cross-compiler in this thread came complete with a link to a tutorial that works perfectly and involves perhaps 10-15 minutes effort on your side (plus some compilation time on behalf of your computer).

Your claims that it would be "a huge pain" and take "hours" are, therefore... misled, to avoid stronger expletives.

The GCC Cross-Compiler tutorial was written as the recommended sollution to problems with:

• inconsistent handling of leading underscores,
• others being unable to reproduce your problem, or others being unable to contribute to a project due to differing host toolchain setups,
• references to runtime environments popping up in your binaries (e.g. _alloca() on Cygwin, or libgcc / libsupc++ references),
• people using standard includes and then wondering why their kernel doesn't work (they get linker errors instead of reboots),

That list is by no means complete.

That tutorial is also recommended to newcomers for years now. The only downside to it is that there always seems to be someone who'll toss in his favourite combination of command line options, dissing the cross-compiler recommendation, and getting pi***d when the regulars here get bored by having the subject pop up again.

No, you don't strictly need a cross-compiler in this case. Yes, the command line options presented would solve the problem just as well.

But building a cross-compiler is still the action recommended here, and I'd very much welcome if we could keep this discussion under ten pages' length.

I haven't ignored anything. I'm not *dissing* cross-compilers. I know the link's there and a pretty good job has been done of explaining how to create one. I just think it's a little overkill for this particular case. However, anyone who plans on taking their OS past these initial stages should definitely sit down and take the time to set up the proper tools -- including cross-compilers if need be.

And, you're right, compiling a cross-compiler won't take hours.... on Linux. It will take at least two to three hours on windows x64 when using Cygwin and Mingw. I have much experience with that. I'd say that your 10-15 minutes prep time is a bit optimistic for newbies though.

Anyway, good luck drax!

10-15 minutes is all it will take if you are comfortable using your current operating system and development environment (which, as listed in the wiki, is a requirement for OSDev). And who cares how long the computer takes, go have a cup of tea or bake a cake or something.

You've also said yourself that you'll need a cross-compiler eventually. So why not get it out of the way to start with, and be done with it? It'll fix this problem, and it'll fix many other problems into the future. That sounds like a good time investment to me.

Pros of creating a cross-compiler:

• Much, much less time spent hunting bugs, now, and in the future (back when I was starting, I spent hours fixing toolchain bugs before I created a cross-compiler.
• Others can reproduce your problems faster.
• You won't piss off forum regulars with 3000+ posts every time you decide to ask a question.

Cons of creating a cross-compiler:

• 50MiB download of source code (very small).
• 10-15 minutes of your time.
• You need to be able to follow instructions for those 10-15 minutes.

That sounds like a good investment to me.

It took about a week of evenings to get gcc, binutils and newlib cross-compiled on my Mac. This includes modifying my makefiles, #includes etc. I like to do some research before I start. This is a very small time investment. Let's be honest, there are years of evenings required to develop even a simple O/S.

-m32 wrote:And, you're right, compiling a cross-compiler won't take hours.... on Linux. It will take at least two to three hours on windows x64 when using Cygwin and Mingw.

*BEEEP*.

Wrong again.

The tutorial has been written for Cygwin (as that was what I was using back when I wrote the first edition of it). It works on Linux more as a side-effect. The only "extra" you have to do on Windows is to install Cygwin, which again is a no-brainer.

-m32 wrote:... when using Cygwin and Mingw ...

I wonder how you plan on using both at the same time...

Please, stop talking rubbish (or bending facts if you like) if you want some credibility. I build crosscompilers for work over lunchbreak on a recent Windows (where it is indeed slower than XP, but not as bad as you suggest)

Solar wrote: *BEEEP*.

Wrong again.

The tutorial has been written for Cygwin (as that was what I was using back when I wrote the first edition of it). It works on Linux more as a side-effect. The only "extra" you have to do on Windows is to install Cygwin, which again is a no-brainer.

ORLY? ಠ_ಠ

Cygwin runs like sh|t on Windows Vista/7 x64. So don't tell me I'm wrong - I've compiled and re-compiled GCC and binutils on these OSes under Cygwin many times (on different machines) trying to find a solution to the incredibly slow compilation problem.

You wrote the tutorial yourself? Well, bravo! You must know it all then right? You must have tested the process on every system right? Well then, I bow before you. I had no idea....

I'm done discussing this. You can keep going if you like, keep preaching!

combuster wrote: I wonder how you plan on using both at the same time...

Are you really that literal combuster? Yeah, that's what I meant, I'm using Cygwin AND Mingw at exactly the same time . It means I've used them both in the past - and recently.

-m32 wrote:I've compiled and re-compiled GCC and binutils on these OSes under Cygwin many times (on different machines) trying to find a solution to the incredibly slow compilation problem.

Type "make all-gcc install-gcc" after dinner and go to bed. Next morning, you've got a cross-compiler.

Sheesh.

Solar wrote:

-m32 wrote:I've compiled and re-compiled GCC and binutils on these OSes under Cygwin many times (on different machines) trying to find a solution to the incredibly slow compilation problem.

Type "make all-gcc install-gcc" after dinner and go to bed. Next morning, you've got a cross-compiler.

Sheesh.

If you're really that troubled by the high compile times (which can be up to as long as a full dinner), try -j 8 on a 4-core machine.

I'm almost tempted to write a script and find out how long it actually took me to build my cross compiler. I'm pretty sure though that I started os deving again last week without any base to start from, and that I now have a 64-bit kernel booting from an ext2fs in bochs using grub, that probes the pci bus & has starts of drivers for two types of devices. I'm pretty sure that I would've spent as much time on the first half of this if I hadn't had a crosscompiler.

JackScott wrote:Cons of creating a cross-compiler:

• 50MiB download of source code (very small).
• 10-15 minutes of your time.
• You need to be able to follow instructions for those 10-15 minutes.

Please don't get me wrong, I fully agree that a custom cross-compiler is definitely the best way to go and I recommend this to anyone who wants to dive into the adventure of OS development.

However, I have a few small comments on this. When I started OS development, I had a slow 56k modem connection, and it would have taken me days to download the full GCC (and Binutils) sourcecode, even if had restricted myself to only C and C++. Some people still have similar restrictions, especially those living in regions with slow internet connection.

When I finally had the GCC source, my first attempt to compile it using CygWin failed, and I did not find any hint on the wiki, so simply following the instructions would not have helped me. Searching Google for the error message (which told me that I used invalid input parameters in some program which was apparently called during the build process) did not help either. By chance I figured out that the build script picked up some program on my windows path and used it instead of the program with the same name shipped with CygWin, and that both had a different command line syntax. Exchanging the paths in my PATH variable solved the problem.

Beginners easily struggle when they encounter problems like these, so there is no reason to blame someone because he fails to build a cross-compiler at the first attempt. For me and also for other experienced programmers this is a very simple task now, because once one knows the caveats, they are easy to overcome, and it's really a matter of minutes (or for me, since I build cross-compilers and debuggers for like 5 or 6 targets from a single build script, about an hour). But even the best tutorial does not account for all unexpected conditions that might occur simply because a beginner doesn't know all of the exact requirements (like in my example, the dependence on the PATH variable).

I think most that can be said has been said (by people at the opposite sides of the spectrum), so I have little to add. However, I must state that no, I do not use a cross compiler. Why? Because I don't need one. I am experienced enough to judge whether I'll need one or not, and I won't make posts here asking about compiler or linker problems resulting from not using a cross compiler. I therefore completely agree with -m32 (what's in a name) that not using one is ok - as long as you know what you're doing.


JAL