Nachrichten

1

Softwareentwicklung / Re: ld und hohe Startadresse

« am: 26. September 2015, 11:24 »

Diese werden ja relativ addressiert.

Werden sie das? Mit '-fpic' (Position Independent Code) wird es natürlich Relativ adressiert, aber sonst.?

Dissasembliere das object file doch vor dem linken mal (objdump -d) und zeig mal was da so um .text+30 so steht.

[EDIT]
Richtige dokumentation habe ich jetzt auf die schnelle nicht gefunden, aber hieraus geht für mich hervor, dass es sich bei R_X86_64_32 um direkte Adressierung handelt, im Gegensatz zu 'R_X86_64_PC32' relativer Adressierung. (PC=Programm Counter=Instruction Pointer=rIP)

2

Softwareentwicklung / Re: GCC für OS compilieren

« am: 26. July 2015, 12:50 »

TEXT_START_ADDR=0x8000000000

Passt nicht in 32-Bit. Also musst du entweder auf die Platzsparende Variante von 32-Bit Adressen verzichten, oder deinen Code wo anders hinlegen.


[edit]

Code: [Auswählen]

-fpic könnte aber evtl auch helfen.

3

Softwareentwicklung / Re: GCC für OS compilieren

« am: 25. July 2015, 17:13 »

Es sieht so aus als würde er beim linken versuchen 64-Bit Adressen in ein 32-Bit Format zu stopfen.

Hilft ein '-m64' ?

Produziert youros-gcc 64-Bit elf (beim compiliren / linken)?

welches format haben die anderen dateien, gegen die du likst (crt0, oder wie die heißt)

4

Softwareentwicklung / Re: GCC für OS compilieren

« am: 12. July 2015, 14:18 »

grep sagt zu dem Makro, das du der einzige bist der es nutzt und

Code: (gcc/system.h) [Auswählen]

869 /* Other obsolete target macros, or macros that used to be in target
870    headers and were not used, and may be obsolete or may never have
871    been used.  */

gcc/config.gcc hat am Anfang eine liste mit variablen und deren Beschreibung. (native_system_header_dir)

5

Softwareentwicklung / Re: GCC für OS compilieren

« am: 12. July 2015, 11:42 »

Ist die fehlermeldung schon von diesem Code?

Hier erst mal ein Fix:

Code: [Auswählen]

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 6bbcc00..68b3f7e 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1746,6 +1746,7 @@ i[34567]86-*-interix[3-9]*)
        ;;
 x86_64-*-youros*)
        tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h i386/i386elf.h i386/x86-64.h youros.h"
+       ;;
 ia64*-*-elf*)
        tm_file="${tm_file} dbxelf.h elfos.h newlib-stdint.h ia64/sysv4.h ia64/elf.h"
        tmake_file="ia64/t-ia64"

Wie compilierst du? Was sind die Konfigurationsparameter?

Eventuell könnte das hier beim Debuggen helfen:

Code: [Auswählen]

$ env -i sh -c 'set -a;target=x86_64-unknown-youros;source gcc/config.gcc;env' > /tmp/youros
$ env -i sh -c 'set -a;target=x86_64-redhat-linux-gnu;source gcc/config.gcc;env' > /tmp/redhat
$ diff -u3 /tmp/youros /tmp/redhat
Es zeigt den unterschied zwischen zwei Target Configurationne an. x86_64-unknown-youros und x86_64-redhat-linux-gnu

6

Softwareentwicklung / Re: GCC für OS compilieren

« am: 11. July 2015, 12:40 »

Für mich sieht es so aus als würde in i386.md etwas bezüglich der Code-Generierung konfiguriert.

Und wenn du dir mal gcc/config.gcc angesehn hast, das ist die einzige Datei in der i386/att.h mal erwähnt wird. Passiert das abhängig vom Compiler TARGET.

Ich nehme also an du musst für dein TARGET in tm_file i386/atth mit aufnehmen.

Oder dein Target so umbenennen das es auf eine dieser Zeilen passt.

Code: (gcc/config.gcc) [Auswählen]

1368 i[34567]86-*-elf*)                                                                                                                                                         
1369     tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h newlib-stdint.h i386/i386elf.h"
1370     ;;
1371 x86_64-*-elf*)
1372     tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h newlib-stdint.h i386/i386elf.h i386/x86-64.h"
1373     ;;


7

Softwareentwicklung / Re: GCC für OS compilieren

« am: 10. July 2015, 22:55 »

Wo sollten diese definiert sein?

Kennst du grep?

Code: [Auswählen]

grep -r ASM_BYTE ${GCC_SOURCE_FOLDER}

Code: [Auswählen]

grep -r "i386/att.h" ${GCC_SOURCE_FOLDER}

8

Softwareentwicklung / Re: GCC für OS compilieren

« am: 01. May 2015, 13:13 »

Ich habe so etwas mit den binutils zwar bis her noch nicht gemacht, aber vielleicht hilft dir das ja trotzdem.

Ich habe jetzt mal versucht binutils-2.25 zu kompilieren mit target mein os.
Leider schlägt es irgendwo fehl und ich weiss nicht wo. Vielleicht wisst ihr ja was das Problem ist.

Hier ist der Fehler:

Code: [Auswählen]

make[4]: Verzeichnis »/home/pascal/Dokumente/cross/src/binutils-2.25_Kopie/ld« wird betreten
/bin/bash ./libtool --tag=CC   --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -g -O2  -static-libstdc++ -static-libgcc  -o ld-new ldgram.o ldlex-wrapper.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o ldwrite.o ldexp.o ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o plugin.o ldbuildid.o eelf_x86_64_youros.o eelf_x86_64.o  ../bfd/libbfd.la ../libiberty/libiberty.a  -lz -ldl -ldl
libtool: link: gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -g -O2 -static-libstdc++ -static-libgcc -o ld-new ldgram.o ldlex-wrapper.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o ldwrite.o ldexp.o ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o plugin.o ldbuildid.o eelf_x86_64_youros.o eelf_x86_64.o  ../bfd/.libs/libbfd.a ../libiberty/libiberty.a -lz -ldl
ldemul.o:(.data+0x0): undefined reference to `ld_elf_x86_64_youros_emulation'
collect2: error: ld returned 1 exit status


ld_elf_x86_64_youros_emulation ist nicht definiert oder kann nicht gefunden werden.

Dateien die eventuell von Interesse sind:
ld/ldemul.{c,h}
  (ldemul.o verweist auf das entsprechende Label)
ldemul-list.h
  wird automatisch generiert und könnte einen Verweis 'ld_elf_x86_64_youros_emulation' enthalten.

ld/emulparams/
ld/emultempl/
  wegen des namens

Du solltest mal versuchen raus zu finden wie dieses 'ld_elf_x86_64_youros_emulation' für andere target platformen definiert ist und das dann entsprechend für YourOS machen.
Es wird sich dabei vermutlich um eine Struktur des Types "ld_emulation_xfer_struct"(ldemul.h) handeln.

Ich hoffe ich konnte ein wenig helfen.

[EDIT:]
Schau dir mal ganz speziell ld/emultempl/linux.em an. Das sieht so aus als würde genau dass für YourOS fehlen.

9

Lowlevel-Coding / Re: GPU Shadereinheiten programmieren mit assembler

« am: 17. December 2014, 14:44 »

Wenn es nicht gleich 20 sein müssen kannst du das auch ein Stückweit mit SIMD befehlen machen.

Die GPU dafür zu nehmen halte ich im Hobby OS Bereich für so gut wie Ausgeschlossen. GPUs sind in der Regel nicht sonderlich gut Dokumentiert und (vermutlich) auch deutlich komplexer zu handhaben.

Wenn wir uns jetzt nicht auf HobbyOS' beschränken geht das natürlich – zumindest mit den passenden Grafikkarten.
Dann wird z.B. in OpenCL Programmiert das ganze dann für die entsprechende Grafikkarte Kompiliert auf die Karte geladen und ausgeführt.

Wenn es dir mehr um Parallelisierung geht und nicht so sehr um OS-Dev sind neben OpenCL, CUDA, HSA (Heterogeneous System Architecture)[GPU] auch OpenMP und Open MPI [CPU] interessant.

10

Lowlevel-Coding / Re: Verständnisfrage zu Paging

« am: 14. December 2014, 14:04 »

In CURRENT_CONTEXT und NEW_CONTEXT hast du jeweils eine ) mehr als du ( hast.

11

Lowlevel-Coding / Re: GCC Fehler

« am: 29. October 2014, 10:01 »

Mit -w schaltest du alle Warnungen aus.

-w    Inhibit all warning messages.

Du nutzt -O0 und -Og. Dabei wird -O0 ignoriert.

-Og [...]
If you use multiple ‘-O’ options, with or without level numbers, the last such
option is the one that is effective.

12

Lowlevel-Coding / Re: GCC Fehler

« am: 17. October 2014, 17:31 »

Die beiden malloc's passen nicht zusammen.
Einmal sind es 2 und einmal nur 1 Parameter.

Was für compiler flags nutzt du denn sonst noch so?
Irgend was in die Richtung "-mcmodel=small" ?

Es wäre auch interessant was danach so mit dem Pointer passiert. (rbx und rax)

13

Offtopic / Re: Hardware Design lernen

« am: 16. April 2014, 15:18 »

Eventuell interessiert dich dieses Buch:
"Digital Design and Computer Architecture"

Danach hat sich unsere Vorlesung zur Technischen Informatik gerichtet. Es behandelt den Entwurf von digitalen Schaltungen mithilfe von HDLs (Verilog und VHDL parrallel). Am beispiel eines MIPS processors.

14

Lowlevel-Coding / Re: GP-Fault beim schreiben von CR0

« am: 18. March 2014, 09:58 »

Korrekt wäre glaube ich Bit 8 (0x100). Möglicherweise erklärt das das komische Verhalten.

Da hat Jidder recht. Und mit nicht eingeschaltetem LM-Bit wird natürlich eine ganz andere Paging Tabelle erwartet. Womit man dann keiner Adresse mehr trauen kann.

Nach dem "movl eax, cr0" wird also vermutlich nichts mehr von dem ausgeführt was da in deinem Listing steht, sondern irgend ein teil deiner Pagingtabelle als Code interpretiert.
Was dann auch erklärt warum er nicht bei 0x1006dd anhält sondern bis 0x100ba2 weiter läuft.

15

Offtopic / Re: ISO erstellen will nicht so Recht

« am: 01. March 2014, 14:18 »

Ja, das Ziel 'iso' hast du erwähnt, aber nicht wie make das erreichen soll/kann.
Make weiß es braucht dafür $(COS).iso, aber auch wie es das erreicht, hast du nirgends beschrieben.
Genauso wenig wie du gesagt hast, wie es aus $(OJBS) den kernel zusammen bauen soll (linken).

Code: [Auswählen]

$(kernel).elf: $(OBJS)
<TAB>befehl(e) zum linken des kernels
<TAB>z.B.: ld -T link.txt -o $(kernel).elf $(OBJS)

$(COS).iso: <liste mit abhänigkeiten, also $(kernel).elf>
<TAB>befehle zum bauen des iso's
<TAB>z.B.:
<TAB>erstellen von ISO_DATA_DIR (alles was aufs iso drauf soll)
<TAB>mkisofs -input-charset UTF8 --quiet -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table -o $(COS).iso /tmp/ISO_DATA_DIR/
BTW:
bei boot.asm hast du einen Tippfehler, es sollte "boot.bin: boot.asm" heißen.

16

OS-Design / Re: Qemu = ok, echt Hardware = Auaa... ;(

« am: 09. February 2014, 22:39 »

Liest du für irgend etwas die BIOS Data Area (BDA) aus? Die liegt nämlich genau bei 0x400.

Hast du denn irgend etwas in der nähe von 0x10444a, bzw. was liegt denn so davor und dahinter ?
Wenn du es nur grob wissen willst oder code weit weg ist kannst du auch mit 'nm <kernel>' nur die labels ausgeben lassen.

17

OS-Design / Re: Qemu = ok, echt Hardware = Auaa... ;(

« am: 07. February 2014, 15:25 »

Wann tritt der Fehler auf?
  Nach dem ersten Timer interrupt. (Siehe Qemu Log)

Was gibt handle_interrupt in diesem Fall zurück?
  new_cpu = schedule(cpu);

Was gibt schedule(cpu) zurück?
  vermutlich: first_task->cpu_state;

Wie ist first_task initialisiert?
  Vermutlich ist hier der NULL-Pointer, der dereferenziert wird.

Falls das doch noch nicht der Fall war, kannst du auch mal versuchen die erste Page nicht zu Mappen. Dein Kernel wird die nicht brauchen. Dann knallt's gleich wenn du einen NULL-Pointer dereferenzierst.

18

OS-Design / Re: Qemu = ok, echt Hardware = Auaa... ;(

« am: 05. February 2014, 23:09 »

Laut Qemu ist kein Paging aktiv!

Laut log ist Paging schon vor dem ersten IRQ aktiv.  (Siehe CR0)
Dass dir Qemu sagt es wäre nicht aktiv, liegt  vermutlich daran, dass du das erst dann abfragst wenn Qemu wegen des Tripplefaults schon wieder rettetet wurde.

19

OS-Design / Re: Qemu = ok, echt Hardware = Auaa... ;(

« am: 05. February 2014, 17:44 »

Die Adresse 0xfff0 sieht verdächtig nach des BIOS-Startadresse aus. Und CR0 verrät dir auch das du dich gerade nicht im Protected Mode befindest.

Sieht also so aus als hätte es auch unter QEMU einen Tripplefault gegeben, nur eben ohne Reboot.

Lass mal alle Interrupts mitloggen qemu -d int … und guck was da so für Exceptions auftreten.

20

OS-Design / Re: Qemu = ok, echt Hardware = Auaa... ;(

« am: 01. February 2014, 16:35 »

Und doch steckt da ein Fehler drin. Du willst da (1 << (index % 32)) haben. Sonst landet in der Bitmap nicht allzuviel freier Speicher^^