Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: berlinermauer am 04. May 2009, 08:24
-
hi, ich habe gcc und ld für windows (minGSW),
so nun kommt bei folgendem aufruf :
ld -T link.txt -o c32kernel.bin
File not recognized : file format not recognized.
Dabei ist das einfach ein obj file
OUTPUT_FORMAT("binary")
INPUT(kernel32.obj ckernel.obj)
ENTRY(start)
SECTIONS
{
.text 0x10200 : {
code = .; _code = .; __code = .;
*(.text)
. = ALIGN(1);
}
.data : {
data = .; _data = .; __data = .;
*(.data)
. = ALIGN(1);
}
.bss :
{
bss = .; _bss = .; __bss = .;
*(.bss)
. = ALIGN(1);
}
end = .; _end = .; __end = .;
}
-
File not recognized : file format not recognized.
Dabei ist das einfach ein obj file
Was für ein Object-Format haben die denn? A.OUT, ELF oder COFF(oder so ähnlich)?
Du musst ein obj-Format verwenden, dass dein Linker unterstützt. Was dein linker unterstützt kannst du dir mit:
$ objdump -i
anzeigen lassen.
-
Also die Beispiele in den Magazinen nutzen das ELF-Binärsystem, allerdings benutzt dein gcc für Windows wahrscheinlich das PE-Format der Standart von Windowsprogrammen. Ich hatte auch die Probleme mit meinem MinGW: glöst habe ich es so, dass ich mit dem Programm objcopy, müsste auch bei dir dabei sein, die pe-datei in elf umgewandelt habe. Die Parameter habe ich nicht im Kopf also gib mal objcopy /? ein, allerdings muss die Pathvariable richtig gesetzt sein!
-
ok aber objcopy gibt mir mehr aus wie ich inner cmd sehen kann, und
laut dem hier : http://linux.about.com/library/cmd/blcmdl1_objcopy.htm
müsste
objcopy -o elf32-i386 kernel32.obj
funktionieren, aber er zeigt mir immer die help an
BTW objcopy pfad ist richt bzw ich mach immer cd...
-
Dann steht ganz oben (vor der Hilfe) sicherlich was objcopy nicht passt.
-
erstes Problem: klick mal mit nem rechts-klick auf die Titelleiste des CMD Interpreten. Dann musst du glaube ich auf eigenschaften und dort kannzt du dann größe des Puffers einstellen, schon kannst du die komplette help sehen, oder noch einfacher objcopy /? > help.txt schon hast du eine datei in dem verzeichniss mit dem inhalt der ausgabe. zweites Problem: du sagst in im Moment nur welche Datei du als Eingabe haben möchtest und die Ausgabedatei elf32-i386 haben soll aber wo geht die Ausgabe hin? Du kannst das eingeben objcopy -o elf32-i386 kernel32.obj kernel32.obj, dann müsste es gehen, er schreibt die Ausgabe gleich wieder in die Datei rein. Da gibt es noch nen praktisches Tool, dass du dabei haben müsstest, heist glaube ich readelf oder so? kuck einfach mal in dem verzeichniss von objcopy, nach einer vergleichbaren Datei. Hoffe ich konnte helfen, wenn dus geschaft hast noch mal posten! :wink:
-
readelf? Oder auch objdump...
-
Also die Beispiele in den Magazinen nutzen das ELF-Dateisystem
Binärformat, nicht Dateisystem.
Ich hatte auch die Probleme mit meinem MinGW: glöst habe ich es so, dass ich mit dem Programm objcopy, müsste auch bei dir dabei sein, die pe-datei in elf umgewandelt habe.
Das ist bestenfalls Gebastel. Die saubere Lösung ist, einen Crosscompiler (http://lowlevel.brainsware.org/wiki/index.php/Crosscompiler_für_Windows) zu verwenden.
-
Man braucht sich nicht mühselig einen Crosscompiler zusammenbasteln oder sich einen Downloaden, natürlich geht das auch ganz prima, aber ich hatte es hallt so gelöst und es funktioniert auch prima.
-
Ich kann irgendwie nicht glauben, dass der normale objcopy unter Windows ELF kann... Zumindest kann meiner unter Linux kein PE.
-
ist aber tatsache, jedenfalls unter MinGW gcc kann hier nur PE dann umwandeln mit objcoopy zu ELF und auch mit NASM den anderen Teil zum ELF-binärformat übersetzen und dann meckert auch ld nicht mehr über verschiedene oder nicht lesbare Binärformate. Funktioniert hier wunderbar bei mir.
-
Also, naja es lag daran dass ich -o statt -O geschrieben hatte,
jetzt meint er aber ebf. unrecognized Format?!!
-
Ich kann irgendwie nicht glauben, dass der normale objcopy unter Windows ELF kann... Zumindest kann meiner unter Linux kein PE.
Doch, ich meine mich auch zu erinnern, daß er das kann. So wurde das ganz am Anfang mit LOST gemacht, glaube ich.
-
Dann versuche es mal, indem du mit NASM deinen Kernel auch mahl in andere Formate zu assemblieren, vieleicht benutzt dein gcc ja noch nen anderes Format. Möglichkeiten elf, aout, pe, coff oder gib einfach mal nasm -fh für die Liste ein und probiere es mal mit jedem Format.
-
jetzt habe ich statt "aout", "elf" benutzt.
C:\gcc\bin\ld.exe: cannot perform PE operations on non PE output file 'c32kernel.bin'.
Das System kann die angegebene Datei nicht finden.
C:\gcc\bin\c32kernel.bin konnte nicht gefunden werden
-
Was hasd du denn vorher eingegeben, bevor die Meldung kam? Ich will dich nicht beinflussen oder so und ich weis ja auch nicht warum du gerade minGSW genommen hast, aber ich würde dir zu MinGW raten, wurde auch schon für irg. ein größerses OS zur entwicklung verwendet.
-
hier der ganze code, die copys und dels kannste ignorieren :
@echo off
nasm -f bin -o kernel16.bin kernel16.asm
REM nasm -f aout -o kernel32.obj kernel32.asm
nasm -f elf -o kernel32.obj kernel32.asm
copy kernel.c C:\gcc\bin\kernel.c
copy link.txt C:\gcc\bin\link.txt
copy kernel32.obj C:\gcc\bin\kernel32.obj
pause
C:\gcc\bin\gcc.exe -ffreestanding -c -Os -o ckernel.obj kernel.c
C:\gcc\bin\ld.exe -T link.txt -o c32kernel.bin
copy C:\gcc\bin\c32kernel.bin c32kernel.bin
del /f /q C:\gcc\bin\kernel.c
del /f /q C:\gcc\bin\link.txt
del /f /q C:\gcc\bin\kernel32.obj
del /f /q C:\gcc\bin\c32kernel.bin
copy kernel16.bin+c32kernel.bin kernel.bin
pause
-
kann mir denn keiner helfen?
-
du brauchst nen cross compiler
bzw einen compiler und einen liker die beide elf ferstehen
-
Und dazu haben wir einen Artikel: http://lowlevel.brainsware.org/wiki/index.php/Crosscompiler_für_Windows
Der sogar im "OS-Dev für Einsteiger" verlinkt ist, aber das scheint ja keiner zu lesen.
-
ich habs gelesen nur war mir das etwas zu komplex und ich glaube vielen "neuen" wird es änlich gehen
-
Es ist halt einfach notwendig/sinnvoll.
-
Sag uns, was genau unverständlich ist. Dann können wir zusehen, daß es verbessert wird.
-
zum einen fängt es schon mit dem verlinkten source an, der nicht mehr da ist, man könnte ihn zwar per google etwas änliches finden aber dann würde alles nicht mehr übereinstimmen und dann müsste man wissen was was ist und wie es anzupassen ist
zu dem man braucht MSYS, oder? wenn ja ist es unter dem link nicht zu finden
-
hm, jo ich hab meinen Server neu aufgesetzt und nicht alle Backups eingespielt. Ich werd das wohl mal tun.
-
Ich weiß nicht ob, aber du weist das man objcopy vor dem linken benutzen musst! Falls es dich Interresiert so mache ich das mit meinem Kernel mit MinGW:
cd /kernel/
del kernel.hax
nasm -fbin -okernel16.bin kernel16.asm
nasm -felf -okernel32.obj kernel32.asm
gcc -ffreestanding -c -Os -o ckernel.obj kernel.c
ld -shared-ffreestanding -Ttext 0x20200 -o kernel32.bin kernel32.obj ckernel.obj
objcopy -O elf32-i386 kernel32.bin kernel32.bin
dd if=kernel16.bin of=kernel32.bin
rename kernel32.bin kernel.hax
del kernel32.obj ckernel.obj kernel16.bin kernel32.bin
-
jetzt kommt das warum auch immer?!
C:\gcc\bin\ld.exe: cannot perform PE operations on non PE output file 'c32kernel.bin'.
-
Dein ld möchte gern eine COFF-Datei haben und du gibst ihm irgendwas anderes. Wenn dieses irgendwas andere ELF ist, dann solltest du darauf achten, dass du nicht nur den Crosscompiler, sondern auch den passenden ld aus den Cross-binutils benutzt.
-
Meine Routine ist so :
@echo off
nasm -f bin -o kernel16.bin kernel16.asm
REM nasm -f aout -o kernel32.obj kernel32.asm
nasm -f elf -o kernel32.obj kernel32.asm
copy kernel.c C:\gcc\bin\kernel.c
copy link.txt C:\gcc\bin\link.txt
copy kernel32.obj C:\gcc\bin\kernel32.obj
pause
C:\gcc\bin\gcc.exe -ffreestanding -c -Os -o ckernel.obj kernel.c
C:\gcc\bin\objcopy.exe -O elf32-i386 kernel32.obj kernel32.obj
C:\gcc\bin\ld.exe -T link.txt -o c32kernel.bin
copy C:\gcc\bin\c32kernel.bin c32kernel.bin
del /f /q C:\gcc\bin\kernel.c
del /f /q C:\gcc\bin\link.txt
del /f /q C:\gcc\bin\kernel32.obj
del /f /q C:\gcc\bin\c32kernel.bin
copy kernel16.bin+c32kernel.bin kernel.bin
pause
was kann daran falsch sein?
-
Welchen Kompiler benutzt du denn nun? mingw? Oder den von PorkChicken?
Und welches Format spuckt dein gcc aus? (Kannst du mit objdump -h nachsehen)
-
Seh ich das richtig, dass du immer noch in link.txt die Dateien kernel32.obj und ckernel32.obj als Input angibst?
Das hier sieht falsch aus:
nasm -f elf -o kernel32.obj kernel32.asm
Der MinGW kann kein ELF. -f win32 ist glaub ich richtig (zweite Wahl ist glaub ich -f coff).
C:\gcc\bin\objcopy.exe -O elf32-i386 kernel32.obj kernel32.obj
Du darfst unter MinGW keine Dateien, die du noch weiterverarbeiten willst, in ELF konvertieren. Zumindest würde dieser Befehl das machen.
Sowas solltest du (wenn überhaupt) erst am Ende machen. Oder wolltest du die Datei ins COFF-Format konvertieren? Das ist hoffentlich nicht nötig, wenn du NASM mit dem richtigen Format aufrufst.
-
Also das einzigste was nicht funtzt ist das ld'en
das objcopy hab ich jetzt mal raus.
ckernel.obj: file format pe-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000030 00000000 00000000 000000b4 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 00000000 00000000 00000000 00000000 2**2
ALLOC, LOAD, DATA
2 .bss 00000000 00000000 00000000 00000000 2**2
ALLOC
3 .rdata 00000018 00000000 00000000 000000e4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
das ist die ausgabe von gcc
aber irgendwie gehts nicht, da er meint dass die ausgabe kein PE Output File wäre.
link.txt OUTPUT_FORMAT("binary")
INPUT(kernel32.obj ckernel.obj)
ENTRY(start)
SECTIONS
{
.text 0x10200 : {
code = .; _code = .; __code = .;
*(.text)
. = ALIGN(1);
}
.data : {
data = .; _data = .; __data = .;
*(.data)
. = ALIGN(1);
}
.bss :
{
bss = .; _bss = .; __bss = .;
*(.bss)
. = ALIGN(1);
}
end = .; _end = .; __end = .;
}
-
Dann gib mal kein OUTPUT_FORMAT an, sondern lass den linker ne PE-Datei ausgeben. Die kannst du dann mit objcopy in eine Binärdatei umwandeln.
-
ich hab jetzt ma das objcopy noch weggelassen und jetzt kommt was ganz anderes :
kernel32.obj: In function `start':
kernel32.asm:(.text+0x1): undefined reference to `main'
komischerweiße?!
Kernel32.asm :
[Bits 32]
extern _main
global start
global _EnableA20Gate
start:
call _main
STOP:
jmp STOP
;#######################################################################
-
Probier mal ein
section .text
am Anfang der kernel32.asm
-
habs vor Bits 32 versucht und dannach, immer noch der Fehler
-
sry für den push weiß aber echt nicht was ich machen kann
-
hast du es jetzt schon mal mit dem CrossCompiler versucht, wenn nicht lasss dir doch von einem forenmitglied einen erstellen, den du dir dann downloaden kannst, dann nur noch pathvariable anpassen :-D
-
Ohja, wer erstellt hier den individuelle Cross Compiler? Bräucht auch einen ^^
Es ist einer im Wiki: http://lowlevel.brainsware.org/wiki/index.php/Crosscompiler_f%C3%BCr_Windows
Ansonsten könntest du den kompletten Quelltext mit Assembler-/Compiler-Aufrufen hochladen, und hoffen, dass jemand den Fehler findet.
-
Die beste möglichkeit wäre ja auf deinem server oder webspace, falls vorhanden eine zip hochzuladen und wir schauen ob es bei uns funktioniert, dann könnte dir unsere konfiguration vieleicht helfen :-D
-
Was genau machst du denn und kommt wirklich außer -1 keine Fehlermeldung?
-
Man kann das mit den Unterstrichen über -fleading-underscore oder -fno-leading-underscore bei gcc einstellen.
Haben mit CHAR* / UCHAR* zu schaffen (kommen beim alten gcc 3.1 nicht).
was soll CHAR* bzw. UCHAR* sein?
Wie sieht deine kernel.ld aus? Der Compiler/Linker ist nur für elf und nicht für PE/COFF. FreakyPenguin würde auch gern das ganze Makefile sehen.
-
Weil es nur gcc und binutils ist? :mrgreen:
-
Warum ist da bei den crosstools kein mingw32-make dabei?
Weil da auch kein Käsebrot dabei is.
Der Aufruf von cmd in der Makefile verursacht übrigens die Probleme, soweit ich weiß.
-
Es gibt das GNU Make, und es gibt einige Versionen davon, die sich die MinGW-Leute für verschiedene Workarounds gebaut haben.
Es ist ein make im MSYS-Paket von MinGW. Dieses Paket ist auch im Artikel zum Cross Compiler genannt.
-
Je mehr Formate, desto besser? ^^
-
Um die Leute mal mit noch mehr langen Links zu verwirren:
Ich vermute Code::Blocks nutzt das etwas neuere mingw32-make 3.81. Das gibts hier: http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=23918 (Man beachte auch das Datum an mingw32-make 3.80-3 ;))
Ein aktuelles make ohne "mingw32" davor gibts unter http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=24963 (Im Paket MSYS-1.0.11-rc1 ist make drin, man braucht nicht noch make-3.81-MSYS-1.0.11-2.tar.bz2.) Man beachte, dass die auf der Homepage immer noch MSYS 1.0.10 als neueste Version verkaufen. Die ist auch schon 5 Jahre alt (und hat make 3.79.1 drin *brrrrr*). Man kann durchaus den 1.0.11-rc1 nehmen, der ebenfalls mit make 3.81 kommt.
-
Endlich hat das jetzt mal geklappt ehenkes! Un du hast es glaube ich fast zu denn meistbesuchtesten themen geschaft! lol :-D
Ich glaub ich nehm mir auch mal noch diesen cross-compiler vor
-
Wenn es hier neue wissenschaftliche Erkenntnisse gibt, denkt ihr bitte auch ans Wiki? ;)
-
ok werd mich vieleicht morgen drumm kümmern, sovern es dann noch kein anderer gemacht hat! fehlen doch noch nen paar antoworten zu den meistbesuchtesten beiträgen
-
Jo, ab knapp zehnmal so vielen Besuchern wird es langsam interessant. ;)
-
sind wir ja auch ehenkes, hier ist so viel los, das es das meiste ist, was ich bis jetzt mitbekommen habe! :-D
-
Ja deine HP mit dem OS-dev Tutorial! Ich muss schon sagen, wenn du damit fertig bist, hast du dort wirklich alles für einen Anfänger zusammengefasst! Das finde ich echt gut, hast du wirklich einen Doktortitel? Daumen hoch für dein Tutorial :wink:
-
Also ich habe mir das in der wiki angeschaut und nach anleitung die bin-utils in das stammverzeichniss meiner windowsplatte verschoben, nach dem download vom angegebenen link. Dannach habe ich msys installiert, ebenfalls durch im Artikel angegebenen link, selbstverständlich auch die paths angepasst! Dann habe ich tyndur übersetzt, dies lief problemlos ab! Allerdings war die übersetzung deutlich langsamer, als unter linux. Probleme gab es allerdings bei der image-erzeugung per make image-hd, liegt aber logischerweise daran, dass er die python-scripte nicht ausführen kann sowie mkf2 oder wie das prog heißt nicht vorhanden ist, deswegen funktioniert die image erzeugung nicht, hat jmd ein workaround? Dies schreib ich dann noch in die wiki, aber ansonsten funktioniert doch alles aus dem artikel, oder was habt ihr zu bemängeln?
-
Ach, irgendwelche Anknüpfungspunkte gibt es immer... Vielleicht kannst du dir dann ja leichter erklären, warum dir der Rechner gerade um die Ohren geflogen ist, nachdem du einen Fehler gemacht hast, oder so. ;)
-
Ja, Ja, der gute alte Hexeditor ist wirklich nützlich wenn man ein OS progt, kann man genau schauen ob die position von Datenstrukturen richtig sitzen, man kann sich verdeutlichen, wie Binärforamte aufgebaut sind etc.! Ich liebe dieses Programm ^^ :-D
-
hm,
also es scheint kein CompilerFehler zu sein. Ich hab mich irgendwo vertan.
http://darkchaos.eu/tuxmaniac_source.rar
-
aber du kannst es compilen?
Warum läuft es nicht in Bochs? kann da nichts machen weil ich es garnicht erst compilen kann
-
Edit:
es liegt an dem Folgenden code :
[Bits 32]
section .text
extern _main
global start
global _EnableA20Gate
start:
call _main
STOP:
jmp STOP
;#######################################################################
-
Das ist übrigens nicht der Code, den du hochgeladen hast ;)
-
doch das ist die kernel32.asm :)
-
In der .rar ist keine kernel32.asm.
-
lol scheiße war ich dumm..
ich hatte die alte source hochgeladen, ohne C kernel...
http://darkchaos.eu/tux.rar