Thema: Executable Loader

[spaceemotion]

Hallo zusammen,
nachdem ich meinen Floppy / Fat Treiber fertig hatte, wollte ich jetzt auch mal Dateien in laden und starten. In Teil 8 des Tutorials, wurde ein ELF-Loader erklärt. Den habe ich auch funktionsfähig (zumindest bei von GRUB übergebenen Modulen) implementiert. Jetzt habe ich vor, die Daten, die ich von der Floppy gelesen habe, als ELF zu starten.
Das Problem ist, dass ich bekomme, wenn ich die ELF Datei starte, einen Invalid Opcode bekomme.

Code: [Auswählen]

char app[size]; //Speicher reservieren
kmemset((void*) &app[0], 0x0, size);//Speicher zu sicherheit putze
readFile( f, size, &app[0] ); //Von der Floppy einlesen
char *appP = &app[0]; //Sonst funktioniert es nicht....
initELF( (void*) appP, 20); //ELF Datei laden
Dazu der ELF Loader:

Code: [Auswählen]


void *initELF(void* image, int pri)
{
    /*
     * FIXME Wir muessen eigentlich die Laenge vom Image pruefen, damit wir bei
     * korrupten ELF-Dateien nicht ueber das Dateiende hinauslesen.
     */
 
    struct elf_header* header = image;
    struct elf_program_header* ph;
    int i;
 
    /* Ist es ueberhaupt eine ELF-Datei? */
    if (header->magic != ELF_MAGIC) {
        kprintf("Keine gueltige ELF-Magic!\n");
        return 0;
    }
 
    /*
     * Alle Program Header durchgehen und den Speicher an die passende Stelle
     * kopieren.
     *
     * FIXME Wir erlauben der ELF-Datei hier, jeden beliebigen Speicher zu
     * ueberschreiben, einschliesslich dem Kernel selbst.
     */
    ph = (struct elf_program_header*) (((char*) image) + header->ph_offset);
    for (i = 0; i < 2/*header->ph_entry_count*/; i++, ph++) {
        void* dest = (void*) ph->virt_addr;
        void* src = ((char*) image) + ph->offset;
 
        /* Nur Program Header vom Typ LOAD laden */
        if (ph->type != 1) {
            continue;
        }
 
        kmemset(dest, 0, ph->mem_size);
        kmemcpy(dest, src, ph->file_size);
    }
 initTask( (void *)header->entry, pri);
    return (void*) header->entry;
}
Ich musste

Code: [Auswählen]

header->ph_entry_count gegen 2 austauschen, weil der Wert bei ungefähr 30 000 liegt.

Die ELF Datei lädt er auch, aber sobald ich einen Syscall von dem ausgeführten Programm aufrufe, geschieht der Invalid Opcode.

Hat einer von euch eine Idee?
S.

[kevin]

Ich schätze mal, es geht irgendwas beim Einlesen schief. Wenn du schon ein Feld im Header nicht benutzen kannst, weil Müll drinsteht, wird ganz sicher auch in anderen Feldern oder im Programm selbst Müll stehen.

Ich würde mir mal einen Hexdump von dem geladenen ELF-Image ausgeben lassen und dann mit der richtigen ELF-Datei vergleichen.

[erik.vikinger]

Hallo,


nur so als Gedanke:  sicher das der Speicher in den die ELF-Datei kommt korrekt gemappt ist, könnte ja sein das da was anderes drin liegt als erwartet.

Ein Hex-Dump der ersten 256 Bytes der geladenen ELF sollte wirklich Licht ins Dunkel bringen können.


Grüße
Erik

[spaceemotion]

@taljeth: Die ELF Magic ist aber immer noch funktionsfähig. Sonst er ja hier abstürzen:

Code: [Auswählen]

if (header->magic != ELF_MAGIC) {
   kprintf("Keine gueltige ELF-Magic!\n");
   return 0;
}Aber er kann ja auch später abstürzen.
@erik.vikinger: Der gesammte hexdump liegt hier. Ist die ELF Datei evt. korrupt?

S.

[erik.vikinger]

Hallo,

Die ELF Magic ist aber immer noch funktionsfähig.

Die Datei ist aber größer als eine Page, möglicherweise sind die Probleme weiter hinten.

@erik.vikinger: Der gesammte hexdump liegt hier. Ist die ELF Datei evt. korrupt?

Das kann ich wirklich nicht beurteilen, ich kenne mich mit ELF nur sehr rudimentär aus. Die entscheidende Frage ist ob das was im Speicher vorliegt auch noch exakt das selbe ist was in der Datei drin ist. Du kennst doch die Größe der Datei, lass Deinen Datei-Loader die ermittelte Größe einfach mal ausgeben und vergleiche. Das nächste wäre eine Prüfsumme über die gesamte Datei (z.B. Adler32, die ist simpel und hierfür ausreichend und reagiert auch auf unterschiedlich lange Folgen von 0-Bytes). Wenn die Größe und die Check-Summe noch stimmen kannst du wenigstens sicher sein das die Datei korrekt und vollständig geladen wurde und der Speicher dafür richtig funktioniert. Als nächstes musst Du dann das Relozieren prüfen, dafür muss der Code der ELF-Datei für den Kernel modifizierbar sein.


Grüße
Erik

[Programm Noob]

Was passiert, wenn du genau die gleiche elf Datei von GRUB laden lässt? geht es dann? wenn ja, dann scheidet die elf Datei als Fehler aus. dann kann es wie schon gesagt am Paging liegen.

PNoob

[kevin]

GRUB lädt nur den Kenel als ELF, und damit er das macht, braucht es auch noch einen Multibootheader, den ein Programm üblicherweise nicht hat...

[Programm Noob]

Ich meinte als Multiboot modul. sollte man aus dem kontext herraus erkennen können.

PNoob

[LittleFox]

GRUB überprüft nicht ob Multiboot Module gültige ELF Dateien sind.
Man kann genauso BMP's oder was ganz anderes Laden lassen.

LittleFox

[Programm Noob]

wollt ihr mich nicht verstehen?
Er soll sich die ELF Datei mit GRUB in den Speicher bevördern lassen und diese dann mit seinem ELF loader laden.

Das man mit Grub alles laden kann ist mir bewusst.
PNoob

[Jidder]

@PNoob:

In Teil 8 des Tutorials, wurde ein ELF-Loader erklärt. Den habe ich auch funktionsfähig (zumindest bei von GRUB übergebenen Modulen) implementiert

[erik.vikinger]

Hallo,

In Teil 8 des Tutorials, wurde ein ELF-Loader erklärt. Den habe ich auch funktionsfähig (zumindest bei von GRUB übergebenen Modulen) implementiert

Genau deswegen denke ich dass das Problem eher beim Laden der ELF-Dateien in den Speicher (über den eigenen Dateisystemtreiber usw.) liegt und nicht beim ELF-Loader (Interpreter) der dann aus der ELF einen neuen Prozess baut.

Für genauere Analysen sind aber mehr Infos von spaceemotion erforderlich, alles andere ist pure Spekulation.


Grüße
Erik

[Jidder]

Code: [Auswählen]

char app[size]; //Speicher reservieren

Ich hoffe das ist nur eine Vereinfachung und liegt nicht wirklich auf dem Stack. Das wäre sonst die Erklärung warum es nicht funktioniert. Den Speicher dafür musst du mit einem vernünftigen Allokator reservieren.

[LittleFox]

@PNoob sorry, wirklich anders verstanden

[spaceemotion]

Tut mir leid, dass ich solange nicht geschrieben haben. Ich musste sehr viel für meine Entwicklungsumgebung tun.
Ich mache jetzt gerade weiter. Die Datei ist komplett korrekt eingelesen. Die Adler32-Summen sind gleich.
Nachdem ich Paging eingebaut habe, erstelle ich für diesen Task (wie für jeden anderen auch) eine eigene Page. Nachdem Wechsel zum neuen Task, gibt es einen GPF.

Wäre nett, wenn sich nochmal jemand melde, obwohl ich solange nicht online war

[Svenska]

Du erstellst für jeden Task eine Page? Dann wird der GPF wohl daher kommen, dass die zweite Page nicht oder falsch gemappt ist. Üblicherweise sind Programme nämlich größer als eine Page...

Gruß,
Svenska

[erik.vikinger]

und Programme (also eigenständige Prozesse) benötigen nicht nur eigene Pages sondern ein komplettes eigenes Paging-Directory das dann diese eigenen Pages verwaltet.

[spaceemotion]

Du erstellst für jeden Task eine Page? Dann wird der GPF wohl daher kommen, dass die zweite Page nicht oder falsch gemappt ist. Üblicherweise sind Programme nämlich größer als eine Page...

Gruß,
Svenska

So, das habe ich jetzt gelöst. Ich mappe genausoviel wie ich brauche. Ich mappe genau soviel wie mein Task braucht.

und Programme (also eigenständige Prozesse) benötigen nicht nur eigene Pages sondern ein komplettes eigenes Paging-Directory das dann diese eigenen Pages verwaltet.

Und hier meinte ich eigentlich auch Pagedirectory und nicht Page. Danke für den Hinweis

Mein Loader funktioniert jedenfalls so wie ich das sehe. Vielen Dank, an alle die sich Gedanken gemacht haben