Nachrichten

1

Softwareentwicklung / Re: Quadratwurzel schnell berechnen

« am: 20. February 2017, 18:04 »

Wichtig ist vor allem, dass die Ergebnisse stetig sind, d.h. nicht irgendwo ein kleinerer Eingangswert ein größeres Ergebnis liefert als ein größerer Eingangswert.

Diese Eigenschaft nennt man nicht stetig, sondern monoton Aber das nur als Randbemerkung.

2

Lowlevel-Coding / Re: x86-Startup

« am: 15. December 2015, 23:55 »

Ich würde den Code mal in Bochs laufen lassen und schauen, was die Log-Datei zum Thema APICs sagt.

Davon abgesehen: Sollte die IPI-Sequenz nicht eher INIT-STARTUP-STARTUP sein? (Wobei der INIT einmal mit "assert" eingeschaltet und mit "deassert" gleich wieder ausgeschaltet wird, danach kommen 10ms Pause, dann STARTUP, dann 200µs Pause, und falls der AP dann nicht läuft noch mal ein STARTUP.)

3

Lowlevel-Coding / Re: Hallo erstmal und "Trying to execute code outside RAM or ROM"

« am: 16. August 2015, 07:57 »

Wenn du QEMU den Parameter -debugcon file:output.txt mitgibst und deinen Bildschirminhalt im Kernel zusätzlich Zeichen für Zeichen mittels out an Port 0xe9 schreibst, findest du ihn hinterher in der Datei output.txt. Ich habe dafür z.B. in meiner putchar-Funktion, die ein Zeichen auf den Bildschirm schreibt, so ein "out %al,%dx" drin.

4

Lowlevel-Coding / Re: Benutzen von Debuggregistern

« am: 19. January 2015, 08:13 »

So weit ich mich erinnere, muss man dafür auch ein paar Flags in den Kontrollregistern setzen (aus dem Kopf weiß ich gerade nicht, welche). Wie sieht denn dein Code dazu aus?

5

Lowlevel-Coding / Re: ELF-Relocatables

« am: 24. December 2014, 19:01 »

Ah, das macht Sinn - oder vielleicht nicht ganz. Dazu habe ich gerade noch etwas gefunden:

As shown above, only Elf32_Rela entries contain an explicit addend. Entries of type Elf32_Rel store an implicit addend in the location to be modified. Depending on the processor architecture, one form or the other might be necessary or more convenient. Consequently, an implementation for a particular machine may use one form exclusively or either form depending on context.

Der Addend müsste also in diesem Fall an der zu relozierenden Stelle selbst stehen, d.h. statt den dortigen Wert zu überschreiben, müsste man B (also die Basisadresse des Relocatables) zu diesem Wert addieren. Einfach A auf 0 zu setzen kommt mir hier falsch vor. Du kannst ja mal schauen, was für Werte denn an den jeweiligen Adressen 0x2190-0x21a8 in der Datei stehen. Ich würde vermuten, das ist nicht 0 (es wäre auch seltsam, wenn da 7 Mal unmittelbar hintereinander der gleiche Wert eingetragen werden sollte).

6

Lowlevel-Coding / Re: ELF-Relocatables

« am: 24. December 2014, 13:37 »

Das wundert mich auch - aus der zugehörigen Dokumentation werde ich auch nicht ganz schlau:

The link editor creates this relocation type for dynamic linking. Its offset member gives a location within a shared object that contains a value representing a relative address. The dynamic linker computes the corresponding virtual address by adding the virtual address at which the shared object was loaded to the relative address. Relocation entries for this type must specify 0 for the symbol table index.

Könntest du die zugehörigen Section-Header und einen Auszug aus der Relokationstabelle (xx-xx-xx-objdump -r bzw. -R für dynamische Relokationen, wobei xx-xx-xx dein Architektur-Triplett ist, also z.B. i386-pc-elf, wenn du einen entsprechenden Cross-Compiler benutzt) posten?

7

Lowlevel-Coding / Re: ELF-Relocatables

« am: 24. December 2014, 00:13 »

Das geht, genau so mache ich es auch im Code von oben (also so gesehen kein 1:1-Mapping, sondern so, wie im Program Header angegeben - wenn du das mit 1:1-Mapping meinst):
http://sourceforge.net/p/xenos/code/HEAD/tree/trunk/kernel/arch/x86/ia32/I386TaskManager.cpp#l212
Man kann also mehrere Segmente haben, die an verschiedene Adressen geladen werden, und die Offsets im Speicher müssen nicht denen in der Datei entsprechen. Genau das berücksichtigt auch mein Beispielcode. Von jedem Segment werden Dateioffset und Speicheroffset ausgelesen und dann der Inhalt an die entsprechende virtuelle Adresse gemappt.

8

Lowlevel-Coding / Re: ELF-Relocatables

« am: 23. December 2014, 14:07 »

So weit ich weiß, sind .dynsym und .dynstr im Prinzip das gleiche wie .symtab und .strtab, enthalten aber speziell die Symbole, die zum dynamischen Linken relevant sind, d.h. die exportierten Symbole. Der Vorteil einer solchen Trennung ist, dass man beim Relozieren / dynamischen Linken nur diese exportierten Symbole nach einem Treffer durchsuchen muss und sie damit von den lokalen Symbolen getrennt hat.

Hier ein Auszug aus meinem Quelltext am Beispiel der IA32-Architektur:
http://sourceforge.net/p/xenos/code/HEAD/tree/trunk/kernel/arch/x86/ia32/I386TaskManager.cpp#l236

In .rel.dyn des Executables findest du eine Liste mit Relokationen, d.h. Stellen im Programmtext, an denen eine Adresse aus der Symboltabelle eingesetzt werden muss. Jede davon zeigt auf ein Symbol aus einer Symboltabelle (die findest du aus dem Link-Feld der Relationstabelle) mit weiteren Infos. Die werden hier ab Zeile 238 gesucht und es wird geprüft, ob es sich um eine Relokationstabelle handelt, und ob auf eine dynamische Symboltabelle verwiesen wird. In 240-242 werden dann die Links zur Relationstabelle, Symboltabelle und Stringtabelle geholt - letztere findest du aus dem Link-Feld der Symboltabelle. Ab 244 wird dann die Relokationstabelle durchsucht. Es wird überprüft, um was für einen Relokationstyp es sich handelt (in diesem Fall ist nur R_386_JMP_SLOT von Bedeutung) und der Index in die Symboltabelle abgefragt. Ab 252 werden dann die exportieren Symbole der Bibliothek (in meinem Beispiel ist das der Kernel, bzw. dessen Low-Level-API, der diese Symbole exportiert) durchsucht und in 254 auf Treffer überprüft. In 256 wird schließlich der gefundene Wert an die Stelle gesetzt, auf die in der Relokation verwiesen wird - die dortige Formel hängt davon ab, welcher Relokationstyp vorliegt, in dem Fall eben R_386_JMP_SLOT.

Bei x86_64 sieht das so ähnlich aus:
http://sourceforge.net/p/xenos/code/HEAD/tree/trunk/kernel/arch/x86/amd64/X86_64TaskManager.cpp#l228

9

Offtopic / Re: intel Dokumente

« am: 22. November 2014, 12:07 »

Das sind ein paar 1000 Seiten Ich glaube, das dauert länger als eine neue Prozessorgeneration zu entwickeln... Da lohnt sich wohl eher, sich die nötigen englischen Begriffe anzueignen, die man dann auch gleich im Kopf behalten kann, wenn man sich mal einer anderen Dokumentation zuwendet.