Kernel Compiling Problems

[endox]

Hi all, i'm new, so Greetings to you all!

After many years of programming i thought it would be great to see if I could write an O/S.
I am using WinXP Pro, MinGW32 and MSYS (Latest versions) as my dev env and NASMW 0.98bf for my assembler.

I am getting all sorts of problems. I have been following the first tutorial "Writing a kernel in C++" and I am still stuck on part one.

The code is exactly the same in my cpp and asm modules as it is on the tutorial.
I compile the kernel.cpp and video.cpp files into object files with g++ using the switches:
-ffreestanding -nostdlib -fno-builtin -fno-rtti -fno-exceptions

and thats all fine and good. I then compile loader.asm with the switch -f aout.
when i use ld i use the following:

ld -o kernel.bin --oformat binary loader.o kernel.o video.o

It then tells me that loader.o is an unrecognised file format.
so i look around the net for a bit to see if others get this problem. I find another output format for NASMW: -f coff

I then run ld with the same switches and i get the error:
PE Operations on non PE file

I try without the --oformat switch and I get the errors:
C:\msys\1.0\mingw\bin\ld.exe: warning: cannot find entry symbol _mainCRTStartup; defaulting to 00401000
kernel.o(.text+0x35):kernel.cpp: undefined reference to `_alloca'
kernel.o(.text+0x3a):kernel.cpp: undefined reference to `__main'

Ok, so now i'm lost.
I think I have spent way too many years working with IDEs so i don't usually have to deal with the linker first hand on a regular basis:)

Anyway, this is really frustrating me because I have enough experience to get my teeth really into this project but I can't due to this problem and I was wondering if anyone could help me past this step.

Cheers big time,
-Endox-

[astrocrep]

You need a linker script, I am pretty sure that that tutorial has one listed on the site (ive used that to help me get rolling w/ C++ in OS DEV) Anyway you when you link you'll need to do something like

Code: Select all

ld -T kernel.ld -o kernel.bin loader.o kernel.o video.o

My linker script looks like this

Code: Select all

OUTPUT_FORMAT("elf32-i386")
ENTRY(start)
SECTIONS
{
    .text 0x100000 :
    {
        code = .; _code = .; __code = .;
        *(.text)
        . = ALIGN(4096);
    }

    .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(4096);
    }

    .bss :
    {
        bss = .; _bss = .; __bss = .;
        *(.bss)
        . = ALIGN(4096);
    }

    end = .; _end = .; __end = .;
}

Take another look on that website, I am 99.9% sure they provide you with all the info you need.

Also dump MinG, and get djgpp and djgpp w/ elf utils from www.osdevers.net I makes things easier for you!

Good Luck

Rich P.

[Solar]

Also dump MinG, and get djgpp and djgpp w/ elf utils from www.osdevers.net I makes things easier for you!

Erm... the FAQ has the following to say on this point:

While DJGPP has been widely used for OS development in the past, it's close connection to MS-DOS and compatibility problems with Windows XP have caused most Windows users to shift to Cygwin or MinGW. DJGPP must be considered obsolete by now.

I strongly second that statement.

[Solar]

I am getting all sorts of problems. I have been following the first tutorial "Writing a kernel in C++" and I am still stuck on part one.

Sorry to hear that; but don't despair - I've done it, and it is possible.

What you ran into is the usual hassle with setting up your development environment. When all you're doing is application programming, you usually care little for binary output formats etc., so this whole issue feels "bumpy" at first. But once you have your compiler, assembler, and linker lined up, it's easy.

The trick is to double- and tripple-check that your compiler, linker, and assembler "speak the same language", i.e. work with a common binary format. Some people here have worked successfully with differing formats converted on-the-fly, but being the pedantic perfectionist I am I never considered walking that road.

While it might sound like overkill, consider building a GCC cross compiler. That was the first thing I did, and looking back, I realized that I avoided a shipload of problems that way. You'll have a "pure" ELF toolchain, and shouldn't have any hassles anymore with linker format errors, alloca() et al.

I think I have spent way too many years working with IDEs so i don't usually have to deal with the linker first hand on a regular basis:)

Prepare for some surprising insights into the inner workings of your everyday tools.

Anyway, this is really frustrating me because I have enough experience to get my teeth really into this project but I can't due to this problem and I was wondering if anyone could help me past this step.

Being one of the C++ advocates here, feel free to pester me with questions.

[astrocrep]

I don't understand why the OSFaq would call djgpp obsolete?

I Have both cygwin (w/ gcc) and djggp

If I goto the djgpp directory and do a gcc -v
Its 3.3.3

My freshly installed CYGWIN comes only with 3.3.1

How is that obsolete... I would appear to me that the OSFAQ is obsolete (not that I am flaming the faq, its got a ton of great info) however, DJGPP no longer shows any signs of winxp compat problems.

Just my 2 cents.

Rich P.

[Tim]

It is obsolete because the DJGPP binaries are all DOS programs, and Cygwin and Mingw are all Windows programs.

Windows XP tries very hard to give DJGPP a DOS-like environment when you run it. DJGPP tries very hard to make DOS look like a protected-mode OS (Unix). There is a huge emulation layer surrounding DJGPP when you run it, both from DJGPP and from Windows.

With Cygwin, on the other hand, no emulation is needed, only a small DLL which provides Windows implementations of the Posix API. Mingw requires even less because it uses the C runtime built into Windows.

DJGPP was created as a port of gcc and binutils to DOS. If you own a copy of either Windows or Linux you should never need to use it.

[Candy]

If I goto the djgpp directory and do a gcc -v
Its 3.3.3

My freshly installed CYGWIN comes only with 3.3.1

ftp://ftp.gnu.org/gnu/gcc/ -> there IS no 3.3.3. The newest is 3.3.2. Are you referring to 3.3?

[Neo]

I have another realted Compilation question.
I presently work on a windows system using DJGPP and NASM. Right now NASM outputs COFF (DJGPP) files I tried changing this to ELF but this didnt work as it was'nt recognised by LD. I then changed the NASM file format to AOUT and it worked. What i'm trying to do is compile under both Windows and Linux. I'm sticking to 'aout' in NASM for now but just wanted to know why 'elf' doesn't work. or is there a better way to do this?

[Tim]

Either obtain a patch to DJGPP which will allow it to recognise ELF files,

OR...
USE CYGWIN
which supports ELF natively (although the linker won't link directly to ELF, you can use objcopy to convert)

[Neo]

im thinking of moving over to CYGWIN but for now i'll stick to AOUT format.

[Candy]

USE CYGWIN

Capitals alone counts as shouting, increasing the size does add some more emphasis. Does this count as abuse?

[Tim]

Is this better?

use cygwin.

[Neo]

much better. Actually i statred using cygwin today and no the nasm elf output is still not being recognised by GCC there either. So i guess im sticking to AOUT for now.

[distantvoices]

Well, cygwin has other nice features too: you download the xfree86 libraries for cygwin, install them and then you can logon to each end every machine in your LAN which offers X-sessions for free. *sssffg*

I could put a CD_ROM image online on my web-site to download for the Not-Cygwin fanatics: it is the whole cygwin installation tree xfree86 included. I'll see to it... It also contains a howto: how to install this stuff and get basic x services shared thou' the LAN.

Stay safe.

PS:
[glow=red,2,300]USE CYGWIN[/glow] --> better I couldna make the timbot.

PPS: Candy, some messages only sink in after shouting them.

[Candy]

PPS: Candy, some messages only sink in after shouting them.

A message should be worded so you remember it without it being shouted to you. Now, since using cygwin nearly offers advantages, why not ask them why they are not using it? Or possibly, offer a feature list, make a page on the OSDEV faq, ask the author of DJGPP to add information about it's 16-bitness more explicitly, of anything, if you want to convince somebody to do something, don't shout.

The only software that you have to force on people should be bad software, and in those cases you're wrong in forcing it on them in the first place. Cygwin is not bad, it doesn't deserve a bad name, don't force it on people.