Hi Folks
Ich versuch mich grad am Blatt 3 von T3.
Habe Datei sump4.s erstellt und abgetippt (alles in emacs).
Habe Datei sump4.c erstellt:
#include <stdio.h>
int main(void)
{
int param, erg;
param = 3;
erg = sump4(param);
printf("%d", erg);
return 0;
}
Nun rufe ich auf:
cc sump4.c sump4.s
bekomme aber folgendes gemeldet
rzdspc3$ cc sump4.c sump4.s
sump4.c:
"sump4.c", line 1: warning: invalid white space character in directive
"sump4.c", line 9: warning: implicit function declaration: sump4
sump4.s:
ld: warning: file sump4.o: attempted multiple inclusion of file
Undefined first referenced
symbol in file
fp sump4.o
main /local/SUNWspro/prod/lib/crt1.o
.sump4 sump4.o
ld: fatal: Symbol referencing errors. No output written to a.out
Auch wenn ich die.s Datei umbenenne, z.B. in unter.s, ist es dasselbe.
Die .s Datei habe ich schon mehrfach kontrolliert, aber ich poste sie sicherheitshalber nochmal, vielleicht hab ich ja was überhört irgendwo:
! Parameter sollte kliener als 58 sein!
.section ".text",#alloc,#execinstr
.align 8
.skip 16
.global .sump4
sump4:
save %sp,-120,%sp
st %i0,[%fp+68]
.L14:
ld [%fp+68],%o4
smul %o4,%o4,%o3
st %o3,[fp-8]
smul %o3,%o4,%o2
st %o2,[%fp-12]
smul %o2,%o4,%o0
st %o0,[%fp-16]
sll %o0,1,%o1
sll %o0,2,%o0
add %o1,%o0,%o1
sll %o2,4,%o0
sub %o0,%o2,%o0
add %o1,%o0,%o2
sll %o3,1,%o1
sll %o3,3,%o0
add %o1,%o0,%o0
add %o2,%o0,%o0
sub %o0,1,%o0
smul %o0,%o4,%o0
st %o0,[%fp-20]
wr %g0,%g0,%y
nop
nop
nop
udiv %o0,30,%i0
jmp %i7+8
restore
.align 8
.file "sump4.c"
Dankeschön
Dein C-Programm "kennt" sump4() ja noch garnicht, wenn du es aufrufen willst; Über die main() muß nochmal die Signatur von sump4() ohne Methode, also "unsigned sump4(unsigned foo);"
Das hat auch nicht geholfen.
Meine .c sieht jetzt so aus
#include <stdio.h>
unsigned sump4(unsigned p);
int main(void)
{
int param, erg;
param = 3;
erg = sump4(param);
printf("%d", erg);
return 0;
}
geht immer noch nicht.
Ungefähr der gleiche output
DOS2UNIX hast Du aber schon auf die Quelltext angewendet? Windows Rechner machen andere Zeilenumbrüche (0x10, 0x13) als UNIX (nur eins von beiden). Daher dürfte das "illegal whitespace" rühren
Ich habe zwar keine Ahnung von Sparc ASM, aber hier:
! Parameter sollte kliener als 58 sein!
.section ".text",#alloc,#execinstr
.align 8
.skip 16
.global .sump4
^^^
sump4:
save %sp,-120,%sp
st %i0,[%fp+68]
.L14:
ld [%fp+68],%o4
smul %o4,%o4,%o3
st %o3,[fp-8]
^^^^
smul %o3,%o4,%o2
<snip>
Jetzt laesst laesst sich, das .c und .s file kompilieren und
erfolgreich linken - eben getestet [img]
http://www.fb18.de/gfx/23.gif[/img]
Edit:
rzdspc3[~/tmp]$ cc -c -o sump4.o sump4.s
rzdspc3[~/tmp]$ cc -o sump4 main.c sump4.o
rzdspc3[~/tmp]$ ./sump4
98rzdspc3[~/tmp]$
Nein Nein
Illegal whitespace ist nicht das prob. Ich habs alles auf der Sparc mit emacs editiert.
Und dein Asm Code ist doch der glecihe den ich gepostet habe
Es funzt immer noch nicht
Wäre cool wenn jemand ne Idee hätte.
Vielleicht kann jemand seinen gesamten Code mit den Commandozeilen anweisungen posten, mit dem er/sie es hinbekommen hat.
Danke nochmal für die Mühe
Ich hab das heute nochmal auf die gleiche Weise probiert, der Code scheint auch zu funktionieren (Keine Fehler beim kompilieren), aber die Ausführung geht irgendwie nicht:
sh-3.00$ cc -c -o sump4.o sump4.s
sh-3.00$ cc -o main main.c sump4.o
die Sachen laufen ohne Fehler durch , aber:
sh-3.00$ ./sump4
funktioniert nicht: Fehlermeldung:
-bash: ./sump4: No such file or directory
woran kann das liegen?
sh-3.00$ cc -c -o sump4.o sump4.s
sh-3.00$ cc -o main main.c sump4.o
Tja, dann würde ich's mal mit
./main probieren…
Ich hab das heute nochmal auf die gleiche Weise probiert, der Code scheint auch zu funktionieren (Keine Fehler beim kompilieren), aber die Ausführung geht irgendwie nicht:
sh-3.00$ cc -c -o sump4.o sump4.s
sh-3.00$ cc -o main main.c sump4.o
die Sachen laufen ohne Fehler durch , aber:
sh-3.00$ ./sump4
funktioniert nicht: Fehlermeldung:
-bash: ./sump4: No such file or directory
woran kann das liegen?
Ich weiss gerade nicht, was diese ganzen Compileroptionen bedeuten. Probiers doch einfach mal mit
cc sump4.s main.cUnd dann führe den Kram aus, indem Du
a.outeingibst.
Nene bloß nicht ohne Ausgabename, a.out stinkt [img]
http://www.fb18.de/gfx/28.gif[/img]
SOurcerer hats schon richtig erfasst, wennd ie Ausgabedatei main genannt wird per -o main, dann muss man auch ./main aufrufen
Und dann führe den Kram aus, indem Du
a.outeingibst.
Wenn schon, dann './a.out' oder 'sh a.out'. Nur 'a.out' dürfte er nicht finden.
3gebhard@rzdspc3$:~ $ echo $PATH
/opt/bin:/local/gnu/bin:/opt/sfw/bin:/usr/openwin/bin:/usr/dt/bin:/usr/bin:/usr/ccs/bin:/local/SUNWspro/bin:/local/TeX/bin:/usr/ucb:.
Auf den RZ-Rechnern ist "." im Path, also kann man sich "./" beim Aufruf schon sparen…
3gebhard@rzdspc3$:~ $ echo $PATH
/opt/bin:/local/gnu/bin:/opt/sfw/bin:/usr/openwin/bin:/usr/dt/bin:/usr/bin:/usr/ccs/bin:/local/SUNWspro/bin:/local/TeX/bin:/usr/ucb:.
Auf den RZ-Rechnern ist "." im Path, also kann man sich "./" beim Aufruf schon sparen…
1. Einige sagen, das '.' im path sei schlechter Stil – dann sollte man sich das weglassen des './'nicht angewoehnen, zumal man dann bei anderen Rechnern nicht weiss, warum es ploetzlich nicht geht.
2. Wenn man so generische Namen wie a.out verwendet, kann in einem der anderen path-Verzeichnisse bereits ein a.out enthalten sein… die Eintraege in der path-Variablen werden doch dieser Reihenfolge nach durchsucht…?
2. Wenn man so generische Namen wie a.out verwendet, kann in einem der anderen path-Verzeichnisse bereits ein a.out enthalten sein… die Eintraege in der path-Variablen werden doch dieser Reihenfolge nach durchsucht…?
So ists. Und ansonsten plättet man sich mit a.out auch ständig die Dateien wenn man alles T3 in einem Verzeichnis macht. Deswegen lieber gleich selber Namen definieren und ./ benutzen
Und ansonsten plättet man sich mit a.out auch ständig die Dateien wenn man alles T3 in einem Verzeichnis macht.
Also ich hatte für jeden Zettel immer ein separates Verzeichnis und dementsprechend nie Probleme. Alles in ein Verzeichnis? Da verliert man doch total die Übersicht!
Und ansonsten plättet man sich mit a.out auch ständig die Dateien wenn man alles T3 in einem Verzeichnis macht.
Also ich hatte für jeden Zettel immer ein separates Verzeichnis und dementsprechend nie Probleme. Alles in ein Verzeichnis? Da verliert man doch total die Übersicht!
Hat immer super geklappt.
blattN.c und blattN.s und blattN als Dateinamen
ich würde immer test.c als dateinamen wählen, gerade unter unix, wenn . in meinem pfad steht …
Hat immer super geklappt.
blattN.c und blattN.s und blattN als Dateinamen
Die .c und die .s Datei hatten den gleichen Namen vor dem Punkt? Hätten sich die .o Kompilate nicht gegenseitig überschreiben müssen?
1. Einige sagen, das '.' im path sei schlechter Stil – dann sollte man sich das weglassen des './'nicht angewoehnen, zumal man dann bei anderen Rechnern nicht weiss, warum es ploetzlich nicht geht.
So ist es - ich benutze schon aus alter Gewohnheit ./foo um Kram zu starten. Nur, gehen tuts halt auch ohne, da der default-Path so gesetzt ist. Und in den anderen Verzeichnissen wird nichts mit Namen a.out liegen - ich vertraue da in die Kompetenz unserer Operatoren…
Aber, alle Zettel in einem Verzeichnis? Unschön, IMO.
1. Einige sagen, das '.' im path sei schlechter Stil
Ich würde sogar sagen, es ist ein Sicherheitsproblem
(wenn der Punkt vorne steht). Sonst legt noch ein böser
Bube ein fieses Skript namens "ls" nach /tmp. Wenn dann
der Admin mal nachsehen will, was so in /tmp liegt…
Edit: wenn der Punkt vorne steht
1. Einige sagen, das '.' im path sei schlechter Stil
Ich würde sogar sagen, es ist ein Sicherheitsproblem.
Sonst legt noch ein böser Bube ein fieses Skript namens
"ls" nach /tmp. Wenn dann der Admin mal nachsehen will,
was so in /tmp liegt…
… wird er mit dem oben angegeben Pfad trotzdem nur den Inhalt von /tmp angezeigt bekommen. Dabei entdeckt er das fiese Skript und schmeißt anschließend den bösen Buben aus dem System.
Und wir sprachen über normale Benutzer. Als Admin bin ich mit '.' im Pfad auch vorsichtiger, als Benutzer habe ich es dort am Ende.
Und wir sprachen über normale Benutzer. Als Admin bin ich mit '.' im Pfad auch vorsichtiger, als Benutzer habe ich es dort am Ende.
Angenommen ein Mitstudent, der z.B. für alle etwas verfügbar macht, packt ein Skript namens "ks" in das Verzeichnis, vielelicht auch einfach in sein Homeverzeichnis oder so. Das Skript gibt "Command not found" aus und macht chmod -R 777 ~ oder löscht irgendwas hübsches bei dir. Das kann als User ärgerlich genug sein, ein vertipper reicht.
Ich würde sogar sagen, es ist ein Sicherheitsproblem.
Sonst legt noch ein böser Bube ein fieses Skript namens
"ls" nach /tmp. Wenn dann der Admin mal nachsehen will,
was so in /tmp liegt…
… wird er mit dem oben angegeben Pfad trotzdem nur den Inhalt von /tmp angezeigt bekommen. Dabei entdeckt er das fiese Skript und schmeißt anschließend den bösen Buben aus dem System.
Stimmt, mit diesem konkreten nicht (hab ich nach dem Posten
gemerkt und geändert, deswegen stimmt das Zitat nicht mehr
mit dem Posting überein). Aber es könnte ja auch jemand auf
die Idee kommen, den vorne reinzuschreiben.
P.S: ich ändere grundsätzlich jedes Posting noch mindestens 2mal [img]
http://www.fb18.de/gfx/10.gif[/img]
I
sh-3.00$ cc -c -o sump4.o sump4.s
sh-3.00$ cc -o main main.c sump4.o
die Sachen laufen ohne Fehler durch , aber:
sh-3.00$ ./sump4
funktioniert nicht: Fehlermeldung:
-bash: ./sump4: No such file or directory
woran kann das liegen?
Das liegt daran, dass der Poster (d.h. ich) bei der Bearbeitung des Postings gepennt hat [img]
http://www.fb18.de/gfx/22.gif[/img]
Jetzt sollte es klappen:
sh-3.00$ cc -o sump4 main.c sump4.o
