nasm Assembler findet include Datei nicht

R

ralli

Guest
Zur Zeit beschäftige ich mich ein wenig mit der Assembler Sprache. Dafür habe ich das Paket nasm installiert. Außerdem bin ich nach unserem FreeBSD Handbuch vorgegangen und habe der Tradition verpflichtet ein erstes Assembler Programm nach Vorlage des Handbuches namens hello.asm codiert:

Code: 
%include    'system.inc'

    section    .data
    hello    db    'Hello, World!', 0Ah
    hbytes    equ    $-hello

    section    .text
    global    _start
    _start:
    push    dword hbytes
    push    dword hello
    push    dword stdout
    sys.write

    push    dword 0
    sys.exit

Bei der Compilierung mit

Code: 
nasm -f elf hello.asm

bricht er mit folgender Fehlermeldung ab:

Code: 
nasm: fatal: unable to open input file `hello.asm'

Es ist natürlich offensichtlich, das die include Datei 'system.inc' nicht gefunden wird. Ich habe lange gesucht, sie aber leider nicht gefunden. Die muß doch das Paket nasm mitinstalliert haben, oder? Wer weiß, wo die steckt, damit ich den Pfad mit angeben kann?

Zum Linken bin ich daher erst garnicht gekommen.
 
Ich Dussel habe das vorherige Kapitel nicht gelesen, worin stand, das ich die include Datei selbst erstellen muß. Das habe ich jetzt nachgeholt. Ich konnte assemblieren und linken ohne jegliche Fehlermeldung.

Wenn ich allerdings das erstellte Binärprogramm hello aus der Konsole starte mit

Code: 
./hello

kommt die Fehlermeldung:

Code: 
./hello: Exec format error. Binary file not executable.

Man was ist das umständlich .... Was ist das nun schon wieder? Gibt es keine fertigen include Dateien und muß ich die immer selbst erstellen?
 
Hab das Binärprogramm ausführbar gemacht mit:

Code: 
chmod +x

es kommt leider die selbe Fehlermeldung. Allerdings war es unter XFCE bereits als ausführbar markiert.
 
Du warst schneller, ja habe ich. Muß möglicherweise noch eine extra Bibliothek installiert werden? Ich denke, ich laß dann doch die Finger davon, denn da fehlen mir die Vorkenntnisse.
 
Hat noch jmand eine Idee?

file hello ergibt:

Code: 
hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped

Müßte es nicht 64-bit sein?
 
Hallo @ralli ,
ralli schrieb:
Müßte es nicht 64-bit sein?
Zum Vergrößern anklicken....
Der Assembler-Code ist für ein IA-32-Bit-System. Du musst dem Linker nur sagen, dass er die Objektdatei auch als solche behandeln soll, was Du mit -melf_i386_fbsd erreichst:
Code: 
ld -melf_i386_fbsd -o hello hello.o

Hier ist ein Beispiel eines „Hello, world“ für ein IA-64-Bit-System.
 
Ich persönlich würde heutzutage Assembler lieber mit fasm anfangen. Kein linken notwendig, kleine und saubere Syntax die nicht so überladenen ist und tolle community. So als kleiner Tipp.
 
marcel schrieb:
Der Assembler-Code ist für ein IA-32-Bit-System. Du musst dem Linker nur sagen, dass er die Objektdatei auch als solche behandeln soll, was Du mit -melf_i386_fbsd erreichst:
Zum Vergrößern anklicken....
Hallo @marcel , danke! Leider kommt die selbe Fehlermeldung. Das Beispiel werde ich mir morgen oder Montag anschauen und durcharbeiten.
 
midnight schrieb:
Ich persönlich würde heutzutage Assembler lieber mit fasm anfangen. Kein linken notwendig, kleine und saubere Syntax die nicht so überladenen ist und tolle community. So als kleiner Tipp.
Zum Vergrößern anklicken....
Dir danke ich auch für den Tipp. Natürlich werde ich mir auch den fasm anschauen und dann berichten. Wird ein wenig dauern, denn Sonntag ist Familientag ....
 
ralli schrieb:
Hallo @marcel , danke! Leider kommt die selbe Fehlermeldung. Das Beispiel werde ich mir morgen oder Montag anschauen und durcharbeiten.
Zum Vergrößern anklicken....

Ich hatte mal ein Programm in IA-32 Assembler für FreeBSD geschrieben, das Sudoku-Puzzle löst: http://freeshell.de/~mk/download/suso.tgz

Gemäß des Makefiles wird das Programm wie folgt gebaut:
Code: 
nasm -f elf -o suso.o suso.asm
ld -melf_i386_fbsd -o suso suso.o
Es baut und läuft auf meinem FreeBSD (amd64) ohne Probleme.

Hinsichtlich Deiner Signatur (DragonFly BSD 5.02 - Hammer Dateisystem - XFCE Desktop - Grafik intern Haswell HD 4600) bin ich etwas irritiert. Hast Du das Beispiel auf FreeBSD oder DragonFly BSD assembliert/ausgeführt?
 
Moin, moin @marcel,

ich bin genau so irritiert wie Du. Ich habe gemäß meiner Signatur alles so ausgeführt unter DragonFly BSD. Also gibt es doch wieder Unterschiede. Ich habe Dein sudoku assembliert und bekomme die selbige Fehlermeldung. Melde mich wieder.
 
Zitat:
DragonFlyBSD is now a 64-bit only distribution. It will no longer compile for a 32-bit target and most of the 32-bit support code has been removed over the past year.
Zum Vergrößern anklicken....

Es scheint also in DragonFly BSD keinen 32-Bit-Kompatibilitäts-Modus mehr zu geben. Du kannst Dich also gleich mit 64-Bit-Assembler befassen.
 
marcel schrieb:
Es scheint also in DragonFly BSD keinen 32-Bit-Kompatibilitäts-Modus mehr zu geben. Du kannst Dich also gleich mit 64-Bit-Assembler befassen.
Zum Vergrößern anklicken....
Und weil es hier Abweichungen gibt, die ich nicht akzeptiere, bleibe ich dann doch lieber bei FreeBSD 11.1. Mit FreeBSD 11.1 hat sich das Problem von selbst erledigt, denn es tritt erst garnicht auf, alles funktioniert so, wie es soll und vorgesehen ist. Es gibt offensichtlich doch eklatante Unterschiede, wenn man tiefer eintaucht.

Danke an alle für Eure Unterstützung.
 
Naja was heißt "Wie es soll?". Erwartest du, dass ein DragonflyBSD sich wie FreeBSD verhalten muss?
 
Rakor schrieb:
Naja was heißt "Wie es soll?". Erwartest du, dass ein DragonflyBSD sich wie FreeBSD verhalten muss?
Zum Vergrößern anklicken....
Nein! Ich erwarte grundsätzlich überhaupt nichts. Das hat den Vorteil, das ich nicht wirklich enttäucht werde. Allerdings bin ich schon überrascht, das es doch ziemliche Unterschiede gibt, die sich mir nicht auf Anhieb offenbaren, sondern erst nach längerer Arbeit zeigen. Ich bin kein Experte und erhebe auch nicht den Anspruch, jemals einer zu werden. Für mich und meine Arbeit sollten die grundlegenden Dinge funktionieren. Bereits die Repos sind schon ziemlich unterschiedlich. Aber all das ist nicht wirklich überraschend und ich möchte es auch nicht weiter diskutieren oder vertiefen. Ich habe bereits viele Male gepostet, das ich von Vergleichen nichts halte. Jeder hat die Freiheit, seine eigenen Erfahrungen zu machen und sich dann zu entscheiden, was zu Ihm paßt.
 
Assembler, is das lang her *-* ich finde es gut das du dich mit der rohesten form der sinnvollen programmierung beschäftigst. Wie man schwer erraten kann sind meine assembler tage schon etwas her, unter freebsd habe ich mich aber vor ca 6 jahren nochmal damit beschäftigt um einige zusammenhänge die bei bsd speziell sind besser zu verstehen. Mein erster ausritt in diese gefilde war vor über 12 jahren nach ewiger wechselei zwischen mehreren hochsprachen, damals wollte ich es genau wissen und hatte mir ein kleines (sehr minimalistisches) os gebaut das von diskette gestartet wurde. Seit dem hat sich viel getan amd64 ist schon recht komplex im vergleich zu x86 16 oder 32 bit daher würde ich anschließend eine empfehlung aussprechen die natürlich nur ein gut gemeinter rat ist :) .

ich habe damals unter (asche über mein haupt) windows angefangen und zunächst mit com output gearbeitet, dabei war der vorteil das man die segmentierung außer acht lassen konnte, denn hier gibt es nur das code segment jedoch startet dein programm bitte an org 0x100H ;). Davor liegen daten (ich glaube ausschließlich der stack). Wenn du dem rat folgen möchtest, kann ich tasm empfehlen, wenn du das im netzt nicht mehr findest könnte ich es evtl. Noch in meinen alten daten finden. Der vorteil bei diesem assembler ist der debuger, der zeigt dir alle x86 16 bit register und deinen ram schön graphisch an, das hilft am anfang ungemein. Wenn du da deine ersten gehversuche geschafft hast (ich empfehle mal mein erstes projekt, exonenzieren nur mit addition und dann am besten im 1. Schritt nur einstellig, danach mehrstellig, das ist relativ einfach und man kommt mit den ersten assembler eigenheiten in berührung die auch schon kniffelig sein können, wenn man neu anfängt), kannst du dir x86 32 und amd64 ansehen und mit bsd loslegen, wo dann aber segmentierung pflicht ist. Aber durch den vorherigen exkurs in die einfache welt von 16 bit und nur code segment hast du dann ein besseres verständniss von dem was deine probleme dann sein werden und bist besser vorbereitet sie zu lösen.

Das ist keine direkte antwort auf das thema jedoch indirekt schon, ich bitte um verständniss der moderatoren :)
sorry für die schreibweise, ich bin gerade per handy on.
viel erfolg beim lehrnen! :)
 
Danke @ath0 für Deine Tipps und guten Wünsche. Bin noch auf der Suche nach einer wirklich guten Einführung für Anfänger. Selber habe ich einige Erfahrungen mit Scriptsprachen, Objektpascal, QT (C++) und Java. Aber das hilft beim Erlernen von Assembler nicht wirklich weiter, so jedenfalls mein allererster Eindruck. Auch zwischen den verschiedenen Assemblern scheint es einige Unterschiede zu geben. Für Sachkundige wird das nichts Neues sein. Im Netz habe ich nicht viele brauchbare Beispiele gefunden. Alles ein wenig defragmentiert und oft aus dem Zusammenhang gerissen. Dein Angebot würde ich gerne annehmen, aber ich bin mir noch nicht im Klaren, ob ich mit Assembler weitermachen soll, sehe auch auf die Schnelle kein Einsatzgebiet bei mir. Der Erkenntnisgewinn liegt wohl darin, mal rein geschnuppert zu haben.:)
 
ralli schrieb:
Dein Angebot würde ich gerne annehmen, aber ich bin mir noch nicht im Klaren, ob ich mit Assembler weitermachen soll, sehe auch auf die Schnelle kein Einsatzgebiet bei mir.
Zum Vergrößern anklicken....
@midnight gab mir einen guten Tipp:
midnight schrieb:
2.) Lerne C programmieren. Aktiviere die Assembler-Ausgabe des Compilers. Jedes Mal, wenn Du eine Funktion erfolgreich kompiliert hast, schaue Dir die vom Compiler generierte Assembler-Ausgabe an. Schaue Dir alle Anweisungen an, die Du noch nicht kennst. Stelle sicher, dass Du verstehst, wie der Assembler-Code dem C-Code entspricht, den Du vorher geschrieben hast. Probiere verschiedene Optimierungsstufen (und andere Compiler-Optionen) aus, um zu sehen, welche Unterschiede diese machen.
Zum Vergrößern anklicken....
Hier ist der Vorteil, dass man im groben weiß was der Code macht und dank C++ musst du nicht bei 0 anfangen
 
Eine gute Idee, die ich bestimmt beherzigen und berücksichtigen werde. Außerdem kann man C immer gebrauchen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben