C/C++ Forum :: Eigenes OS?

abc.w Mitglied 00:03:02 28.03.2009 Titel:

@rapso: Wollte an dieser Stelle ein Paar Kommentare abgeben, ich denke, ich lasse es lieber sein. Wir haben unsere Meinungen gesagt und jeder kann sich über das Gesagte eigene Meinung bilden.

Ich versuche grade verzweifelt, mit meinen Werkzeugen mingw-gcc und dem Linker, der dabei ist, den Kernel zu kompilieren. Es geht leider nicht. Bekomme Fehlermeldung (habe --verbose beim Linker angegeben, damit die Ausgabe ausführlicher wird):

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30	C:\BochsMyOS\20090326_eh_os>make c:\nasm-2.06rc6\nasm.exe -O32 -f bin boot.asm -o boot.bin c:\nasm-2.06rc6\nasm.exe -O32 -f aout kernel.asm -o kernel.o gcc -c ckernel.c -o ckernel.o ld -T kernel.ld kernel.o ckernel.o --verbose GNU ld version 2.17.50 20060824 Supported emulations: i386pe using external linker script: ================================================== OUTPUT_FORMAT("binary") ENTRY(RealMode) SECTIONS { .text 0x8000 : { (.text) } .data : { (.data) } .bss : { (.bss) } } ================================================== attempt to open kernel.o succeeded opened script file kernel.o kernel.o: file not recognized: File format not recognized make: ** [all] Error 1

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30	C:\BochsMyOS\20090326_eh_os>make c:\nasm-2.06rc6\nasm.exe -O32 -f bin boot.asm -o boot.bin c:\nasm-2.06rc6\nasm.exe -O32 -f aout kernel.asm -o kernel.o gcc -c ckernel.c -o ckernel.o ld -T kernel.ld kernel.o ckernel.o --verbose GNU ld version 2.17.50 20060824 Supported emulations: i386pe using external linker script: ================================================== OUTPUT_FORMAT("binary") ENTRY(RealMode) SECTIONS { .text 0x8000 : { (.text) } .data : { (.data) } .bss : { (.bss) } } ================================================== attempt to open kernel.o succeeded opened script file kernel.o kernel.o: file not recognized: File format not recognized make: ** [all] Error 1

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30	C:\BochsMyOS\20090326_eh_os>make c:\nasm-2.06rc6\nasm.exe -O32 -f bin boot.asm -o boot.bin c:\nasm-2.06rc6\nasm.exe -O32 -f aout kernel.asm -o kernel.o gcc -c ckernel.c -o ckernel.o ld -T kernel.ld kernel.o ckernel.o --verbose GNU ld version 2.17.50 20060824 Supported emulations: i386pe using external linker script: ================================================== OUTPUT_FORMAT("binary") ENTRY(RealMode) SECTIONS { .text 0x8000 : { (.text) } .data : { (.data) } .bss : { (.bss) } } ================================================== attempt to open kernel.o succeeded opened script file kernel.o kernel.o: file not recognized: File format not recognized make: ** [all] Error 1

Anscheinend kennt der mingw Linker den aout Format nicht.

Kennt jemand einen Workaround?

Erhard Henkes Mitglied 00:52:53 28.03.2009 Titel:

Zitat:

Anscheinend kennt der mingw Linker den aout Format nicht.

Kennt jemand einen Workaround?

Guter Hinweis. Ich verwende gcc 3.1 (im DJGPP-Paket)
http://www.osdever.net/downloads/compilers/DJGPP-Installer-nocpp.exe , weil diese Version bei Bona Fide zum Download angeboten wird.

Ich wusste, dass mit C das Gewurschtel mit den Tools los geht, aber dafür ist das Programmieren jetzt deutlich einfacher.

Erhard Henkes Mitglied 01:54:19 28.03.2009 Titel:

Wie kann man den gcc umstellen auf Intel Syntax? War das -masm=intel beim gcc?

Wie heisst das dann korrekt in Intel Syntax?

C/C++ Code:
inline void outportb(unsigned int port,unsigned char value) { asm volatile ("outb %%al,%%dx"::"d" (port), "a" (value)); };

C/C++ Code:
inline void outportb(unsigned int port,unsigned char value) { asm volatile ("outb %%al,%%dx"::"d" (port), "a" (value)); };

C/C++ Code:
inline void outportb(unsigned int port,unsigned char value) { asm volatile ("outb %%al,%%dx"::"d" (port), "a" (value)); };

Bitsy Mitglied 06:41:43 28.03.2009 Titel:

Ich glaube so einfach geht das nicht.
Allerdings sollte der NASM mit aout zurechtkommen (fette Zeile).

Aus der DJGPP-FAQ:
Unter Punkt 17.1 werden einige Problembehandlungen aufgezeigt. Dann:

17.2 Converting between Intel ASM syntax and AT&T syntax

Q: Where can I find an automated conversion tool to convert my Intel-style assembly code into a code acceptable by Gas?
Q: Where can I find a converter from AT&T assembly to Intel style?
A: A SED script which should do most of the conversion was posted to the {DJGPP news group}.

A program called TA2AS which can convert TASM assembly source to AT&T style can be found {on the DJGPP server} and {on Oulu}. TA2AS was written by Frank van Dijk of the Spirit group; if you have questions about this tool, you may contact {Jan Oonk}. The authors say that the program is far from finished, but the sources are available with the package so you can fix whatever is broken for your needs.

Another similar converter is Intel2Gas, available from its {Web page}.

Beginning with Binutils 2.10, Gas has an option that causes it to accept the Intel syntax, so you can use Gas to assembly Intel-style code.

Alternatively, here is what you can do to make your code linkable with DJGPP programs:
* Get and install NASM, a portable x86 assembler which supports most of the Intel syntax and can generate DJGPP-compatible COFF object files (as well as lots of other formats, such as Microsoft 16-bit OBJ and Win32, a.out, and ELF). It also supports Pentium and Pentium Pro opcodes, and MMX. NASM is free for non-commercial use (see the docs for commercial use restrictions) and can be compiled with DJGPP. NASM can be found {on NASM Web site}, which has links to official download sites. The maintainers of NASM are {Jules} and {H. Peter Anvin}.

Be warned that NASM is not 100% identical to MASM or TASM. Even experienced assembly programmers might need some time to adapt to the slightly different flavor of NASM. If you want something much more similar to TASM, get JAS. JAS is available {from OULU}.

Also note that NASM, or at least some of its versions, doesn't produce debug info in the format understood by GDB, which makes debugging NASM-assemblied code tedious (you might not be able to display source lines and refer to local symbols by name). Latest versions of NASM might correct this deficiency.
* For a small number of relatively short files, consider converting them with a smart editor (like Emacs or its work-alikes).
* Obtain a copy of Microsoft MASM 6.11. It has a -coff option to generate object code in COFF format which can be submitted to GCC, so you can compile your original source. You can also use the LIB32 librarian from Microsoft C8 to convert object files to COFF by putting them into a .lib library, then extracting them as COFF files. {28} Note that, unless you link the MASM-generated object files with DJGPP's ld (as opposed to Microsoft's LINK /CO command), you won't be able to debug the resulting program, because the debug info is not in correct format. I'm also told that masm doesn't produce sections named ".text" and ".data", so you might need to hex-edit the section names in the object file manually.
* Use a disassembler to disassemble the object code, then convert it to the AT&T format either by hand or using TA2AS. One place to look for such a disassembler is {on SimTel.NET mirrors}.
Keep in mind that syntax is only one of the aspects of converting code written for DOS to DJGPP. You should also make sure your code doesn't violate any of the rules for protected-mode programming (see {GPF in asm code}).

If you need to perform the opposite conversion, from the AT&T style to the Intel style, try the Att2Intl converter written by {Gregory Velichansky}. Its output is intended for NASM or TASM. Att2Intl is available {from Greg's home page}.

Der komplette Punkt 18 der FAQ mit Informationen über low-level-programming könnte auch noch die eine oder andere wertvolle Information beinhalten.
Wenn da noch die eine oder andere Komponente vom DJGPP fehlt, ich hab da noch Unmengen von Resourcen rumliegen.

Erhard Henkes Mitglied 12:10:28 28.03.2009 Titel:

-- verbose ist ein guter Hinweis. Bei mir sieht dies so aus, noch ein problem mit partcopy.exe, aber es läuft alles:

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37	G:\OSDev\Test\13 C>make nasmw -O32 -f bin boot.asm -o boot.bin nasmw -O32 -f aout kernel.asm -o kernel.o gcc -c ckernel.c -o ckernel.o ld -T kernel.ld kernel.o ckernel.o --verbose GNU ld version 2.13 Supported emulations: i386go32 using external linker script: ================================================== OUTPUT_FORMAT("binary") ENTRY(RealMode) SECTIONS { .text 0x8000 : { (.text) } .data : { (.data) } .bss : { (.bss) } } ================================================== attempt to open kernel.o succeeded kernel.o attempt to open ckernel.o succeeded ckernel.o rename a.out ckernel.bin cmd /c copy /b boot.bin + ckernel.bin MyOS.bin boot.bin CKERNEL.BIN 1 Datei(en) kopiert. partcopy MyOS.bin 0 1000 -f0 Failed to read source at offset 800make.exe: ** [all] Error -1

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37	G:\OSDev\Test\13 C>make nasmw -O32 -f bin boot.asm -o boot.bin nasmw -O32 -f aout kernel.asm -o kernel.o gcc -c ckernel.c -o ckernel.o ld -T kernel.ld kernel.o ckernel.o --verbose GNU ld version 2.13 Supported emulations: i386go32 using external linker script: ================================================== OUTPUT_FORMAT("binary") ENTRY(RealMode) SECTIONS { .text 0x8000 : { (.text) } .data : { (.data) } .bss : { (.bss) } } ================================================== attempt to open kernel.o succeeded kernel.o attempt to open ckernel.o succeeded ckernel.o rename a.out ckernel.bin cmd /c copy /b boot.bin + ckernel.bin MyOS.bin boot.bin CKERNEL.BIN 1 Datei(en) kopiert. partcopy MyOS.bin 0 1000 -f0 Failed to read source at offset 800make.exe: ** [all] Error -1

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37	G:\OSDev\Test\13 C>make nasmw -O32 -f bin boot.asm -o boot.bin nasmw -O32 -f aout kernel.asm -o kernel.o gcc -c ckernel.c -o ckernel.o ld -T kernel.ld kernel.o ckernel.o --verbose GNU ld version 2.13 Supported emulations: i386go32 using external linker script: ================================================== OUTPUT_FORMAT("binary") ENTRY(RealMode) SECTIONS { .text 0x8000 : { (.text) } .data : { (.data) } .bss : { (.bss) } } ================================================== attempt to open kernel.o succeeded kernel.o attempt to open ckernel.o succeeded ckernel.o rename a.out ckernel.bin cmd /c copy /b boot.bin + ckernel.bin MyOS.bin boot.bin CKERNEL.BIN 1 Datei(en) kopiert. partcopy MyOS.bin 0 1000 -f0 Failed to read source at offset 800make.exe: ** [all] Error -1

Schwachstellen: letzte Zeile (jemand eine Idee?), und ich müsste ckernel.bin vorher löschen, damit a.out umbenannt werden kann. Gibt es da einen Parameter für rename, das auf jeden Fall zu machen, auch, wenn ckernel.bin existiert?

Für das Problem von abc.w habe ich momentan keine Lösung, ich war schon froh, dass ich selbst das Linken geschafft habe. Aber vielleicht schaffen wir es gemeinsam, eine möglichst allgemeingültige Lösung zu finden.

Erhard Henkes Mitglied 12:14:19 28.03.2009 Titel:

bei abc.w: i386pe
bei mir: i386go32

Ich habe nochmal genau geschaut (also nicht Version (war wohl DJGPP) 2.03, sondern 3.1): GCC 3.1 C compiler binaries for DJGPP

Zitat:

ld --version
GNU ld version 2.13

gcc --version
gcc.exe (GCC) 3.1

Das att2intl Tool findet man übrigens hier:
http://www.bumba.net/~hmaon/a2i/

@Bitsy: Danke für den Hinweis!

Unregistrierter

Erhard Henkes schrieb:

Mich würde auch eure Meinung zum kurzen Abschnitt "Gerätetreiber" interessieren:
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId220571

Zitat:

In unserem OS müssen wir uns nun zumindest auf die rudimentärsten Operationen konzentrieren, nämlich Videoausgabe (monochrome/farbige Text/Grafik-Ausgabe), Dateneingabe über Tastatur und Daten lesen/schreiben von/auf formatierte(r) Floppy Disk. Maus, Drucker, Festplatte könnten später folgen, wenn notwendig.

ich würde schon mal versuchen, das ganze modular aufzubauen, so dass z.b. die text-ein/ausgabe, gerätesteuerung usw. über einheitliche schnittstellen gehen, also funktionen wie 'putchar()' und 'getchar()' umgeleitet werden können, indem man z.b. intern pointer auf strukturen umsetzen kann. dazu könntest du dir eine generische 'driver' struktur definieren, die bestandteil spezialisierter strukturen ist (objektorientierung also (nein, nicht c++ benutzen!!), so dass später leicht andere geräte eingehängt werden können). bewährt hat sich auch ein 'handle'-konzept, sowas wie stdin, stdout, file, raw, etc. der bastelfreudigkeit sind keine grenzen gesetzt.

Erhard Henkes Mitglied 15:23:54 28.03.2009 Titel:

Ich habe mal dieses "halbfertige" Tool att2intl.exe eingesetzt:
man gibt z.B. asmcode.s (ATT) ein und erhält asmcode.asm.

Beispiel:

Code:
"outb %%al,%%dx"::"d" (port), "a" (value)

Code:
"outb %%al,%%dx"::"d" (port), "a" (value)

Code:
"outb %%al,%%dx"::"d" (port), "a" (value)

==>

Code:
"out BYTE ["a" +value], BYTE %dx":[:"d" +port], %al

Code:
"out BYTE ["a" +value], BYTE %dx":[:"d" +port], %al

Code:
"out BYTE ["a" +value], BYTE %dx":[:"d" +port], %al

allerdings funktioniert

C/C++ Code:
inline void outportb(unsigned int port,unsigned char value) { asm volatile ("out BYTE ["a" +value], BYTE %dx":[:"d" +port], %al); };

C/C++ Code:
inline void outportb(unsigned int port,unsigned char value) { asm volatile ("out BYTE ["a" +value], BYTE %dx":[:"d" +port], %al); };

C/C++ Code:
inline void outportb(unsigned int port,unsigned char value) { asm volatile ("out BYTE ["a" +value], BYTE %dx":[:"d" +port], %al); };

mit gcc -c ckernel.c -o ckernel.o -masm=intel nicht.

Zitat:

ckernel.c: In function `outportb':
ckernel.c:39: parse error before "a"

Kann da jemand bitte etwas nachhelfen? Ansonsten bleibt es eben bei der AT&T-Sysntax.

Erhard Henkes Mitglied 15:29:36 28.03.2009 Titel:

@abc.w: Konntest Du das Problem lösen? Möchte niemanden verlieren.

Zitat:

The other main snag concerns object-file formats. There are two variants of the 32-bit COFF format: one used by Microsoft Win32 tools, and one by the rest of the world. They are only subtly different, and linkers which expect one format will happily link the other. The difference comes in the relocations: if you write code in, say, NASM, and link it using the Microsoft linker along with some modules compiled using Visual C++, the addresses in the final output will come out wrongly. Thereâ€™s no real workaround for this, but luckily most tools that work with the PE format will allow you to emit files in the Win32 format: NASM has its -f win32 option, and Cygwin has the pei-i386 output format.

Zitat:

For LD (the linker that is most often used with DJGPP and gcc) use the option --oformat binary.

EDIT: delete (gelöst): del (anstelle delete; einer meiner Uraltfehler) u. -o beim Linker

Erhard Henkes Mitglied 15:31:30 28.03.2009 Titel:

@+fricky:

Zitat:

generische 'driver' struktur definieren, die bestandteil spezialisierter strukturen ist

hast du einen Link oder ein beispiel-OS vor Augen. würde mir das gerne mal an einem konkreten beispiel anschauen. thema passt momentan genau, bin da dran.