Seite 1 von 2

GCC Optionen

Verfasst: Di 17. Jan 2006, 17:37
von eber
Da ich (wie vermutlich andere TAPler auch) teilweise massiv Probleme durch falsche Pointer oder Bufferoverflows bzw. unzulässige Indexes bei Arrays habe/hatte und deswegen schon mehrfach die Sprache C verflucht habe, habe ich mal Google nach einer Möglichkeit gesucht, wie man dem GCC eventuell dazu überreden könnte, Code zu erzeugen der die entsprechenden Prüfungen vornimmt.

Es gibt tatsächich wohl GCC-Varianten, die so etwas können und so wie es aussieht versteht "unser" GCC diese Option schon ab Werk !!!!

mips-gcc.exe -O2 -c -mtap -mlong-calls -msoft-float -fbounds-check -I..\ -I ..\include -I c:\cygwin\usr\include -I c:\cygwin\usr\local\include %1 %2 %3 %4 %5 %6 %7 %8 %9

zumindest meckert er bei dieser Option nicht (im Gegensatz zu einer frei erfundenen).
Allerdings könnte es auch sein, das er die Option zwar akzeptiert aber auch ignoriert.
Falls letzteres nicht der Fall ist wäre es noch interessant zu wissen, was den im Falle eines erkannten Laufzeitfehlers konkret passiert bzw. wie man mit eigenem Code dann reagieren kann.
Leider kenne ich mich mit Linux / GCC etc. eigentlich nicht aus - daher die Frage an die Gurus...

Wenn es möglich wäre dieses Feature zu nutzen würde die Fehlersuche in Taps extrem erleichtert - es wäre einfach genial.

Grüße

Eber

Verfasst: Mi 18. Jan 2006, 00:15
von Jag
Hallo eber,
eber hat geschrieben:mips-gcc.exe -O2 -c -mtap -mlong-calls -msoft-float -fbounds-check -I..\ -I ..\include -I c:\cygwin\usr\include -I c:\cygwin\usr\local\include %1 %2 %3 %4 %5 %6 %7 %8 %9
Ich habe die Option "-fbounds-check" testweise mal hinzugefügt, ob mit oder ohne, die erzeugten TAP's waren binär identisch!
Demzufolge hatte diese Option keinen Einfluss auf den erzeugten Code!

Erzeuge einfach mal ein TAP mit und dann ohne die Option und vergleiche dann die beiden TAP's nach Inhalt!


Gruß
Jag

Verfasst: Mi 18. Jan 2006, 09:16
von eber
@Jag:
Habe es inzwischen selbst mal probiert und dabei nur die Länge des generierten Files verglichen. Leider absolut identisch.
Es gibt aber im Internet Patches, mit denen man das dem GCC-Compiler beibringen kann. Allerdings muß man dazu den Compiler selbst neu compilieren (wenn ich es richtig verstanden habe) und davon habe ich keine Ahnung.

Wenn jemand so etwas schon mal gemacht wäre es toll, wenn er sich hier melden könnte.

Grüße

Eber

Verfasst: Mi 18. Jan 2006, 10:08
von DeJe
Dazu benötigst Du auf jeden Fall den Source für den Topf-GCC.
Hast Du den?

Verfasst: Mi 18. Jan 2006, 10:15
von Erdnussnase
Viel schlimmer wirkt sich bei mir immer der Bug aus, das Pointer, die man zur Compilezeit zuweist nicht vom Linker/Loader auf die richtige Adresse gepatcht werden.
Das muß man ja immer selbst machen und das vergesse ich leider viel zu häufig :cry:

Verfasst: Mi 18. Jan 2006, 10:41
von hagge
Erdnussnase hat geschrieben:Viel schlimmer wirkt sich bei mir immer der Bug aus, das Pointer, die man zur Compilezeit zuweist nicht vom Linker/Loader auf die richtige Adresse gepatcht werden.
Das muß man ja immer selbst machen und das vergesse ich leider viel zu häufig :cry:
Kann man da nicht beim Linker eine entsprechende Ladeadresse angeben? Irgendwas mit "--section-start SECTIONNAME=ORG" oder "-Tbss ORG" oder "-Tdata ORG"? Auf jeden Fall müsste sich das durch Anpassen des Linkerskript-Files erledigen lassen.

Gruß,

Hagge

Verfasst: Mi 18. Jan 2006, 10:46
von Happy
Erdnussnase hat geschrieben:Viel schlimmer wirkt sich bei mir immer der Bug aus, das Pointer, die man zur Compilezeit zuweist nicht vom Linker/Loader auf die richtige Adresse gepatcht werden.
Das muß man ja immer selbst machen und das vergesse ich leider viel zu häufig :cry:
Du meinst die Sachen mit den Pointerarrays, das ist wirklich ärgerlich. :motz:


Hat von Euch schon jemand mit dem alternativen, und im Sourcode und für mehrere Plattformen verfügbaren Compiler "Topfield TAP Toolchain Creator " gearbeitet ?
Infos und Download hier

Ich hatte selbst leider noch keine Zeit das mal zu installieren.

Gruß,
Happy

Verfasst: Mi 18. Jan 2006, 10:47
von jk
es gibt doch irgendwo die scriptsammlung zum bau des cross-gcc unter linux für den topf, da müßte man in richtung win-version eingreifen.

hat mal eben jemand den link da dazu?

Verfasst: Mi 18. Jan 2006, 11:25
von Happy
jk hat geschrieben:es gibt doch irgendwo die scriptsammlung zum bau des cross-gcc unter linux für den topf, da müßte man in richtung win-version eingreifen.

hat mal eben jemand den link da dazu?
MeinLink von oben weist auf fetige binaries, inkl Sourcen für Windows mit cygwin, Mac, Linux und Solaris.

Gruß,
Happy

Verfasst: Mi 18. Jan 2006, 14:05
von ibbi
Es gibt einige Optionen, die man nutzen kann, um bereits vom Compiler auf "suspekte" Stellen im Quellcode hingewiesen zu werden. Ich nutze z. B. gerne

Code: Alles auswählen

-pedantic -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
Erscheinen mit diesen Optionen Warnungen beim Kompilieren, sollte man sich den Quellcode besser noch einmal ansehen. (Wer damit mal die Source-Beispiele von Topfield übersetzt, bekommt einen Eindruck von der Sorgfalt, mit welcher dort entwickelt wird. :? )

Verfasst: Mi 18. Jan 2006, 14:50
von eber
ibbi hat geschrieben:Es gibt einige Optionen, die man nutzen kann, um bereits vom Compiler auf "suspekte" Stellen im Quellcode hingewiesen zu werden. Ich nutze z. B. gerne

Code: Alles auswählen

-pedantic -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
Erscheinen mit diesen Optionen Warnungen beim Kompilieren, sollte man sich den Quellcode besser noch einmal ansehen. (Wer damit mal die Source-Beispiele von Topfield übersetzt, bekommt einen Eindruck von der Sorgfalt, mit welcher dort entwickelt wird. :? )
Diese Optionen nutze ich bereits aber gegen Bufferoverflows und Co helfen sie eigentlich auch nicht.
Ich hoffe allerdings auch, das der Programmierer der die Sourcecode-Beispiele bei Topfield gebastelt hat nicht auch an der Firmware mitarbeitet :) aber das ist wohl Wunschdenken :lol:

Grüße

Eber

Verfasst: Mi 18. Jan 2006, 15:01
von eber
Happy hat geschrieben:MeinLink von oben weist auf fetige binaries, inkl Sourcen für Windows mit cygwin, Mac, Linux und Solaris.

Gruß,
Happy
Ich denke mal, das man zum Neukompilieren vermutlich mehr C-Kenntnisse und auch Linux-Know how braucht als ich habe. Leider programmiere ich seit Jahren nur noch hobbymäßig :?

Wenn es jemand schaffen würde diese Patches in den GCC zu integrieren würde ihn mein Dank bis ans Ende aller Tage verfolgen


Grüße

Eber

Verfasst: Mi 18. Jan 2006, 15:37
von DeJe
@Happy, gibt es für den Toolchain Installations-/Setup-Anweisung für Windows-basierende Systeme? Ich finde nur man-pages die mir nicht wirklich viel helfen. ;)

Wichtigste Frage ist, wie stelle ich die Umgebung richtig ein. Ich hab zwar alles unter cygwin entpackt. Aber wie geht es weiter? Den Konfort mit VS 2005 zu entwickeln möchte ich eigentlich nicht missen.

Verfasst: Mi 18. Jan 2006, 15:50
von jk
ich versuch es eben auf einem linuxrechner zu kompilieren, unter cygwin hab ich leider nix zusammengebracht

Verfasst: Mi 18. Jan 2006, 16:15
von Happy
DeJe hat geschrieben:@Happy, gibt es für den Toolchain Installations-/Setup-Anweisung für Windows-basierende Systeme? Ich finde nur man-pages die mir nicht wirklich viel helfen. ;)
Wie schon gesagt, habe ich es selbst noch nicht verwendet.
Habe nur noch ein paar Links zusamengetragen
Berlios-Doku
UK-Forum-Thread
Thread im Australischen Forum

Irgendwo stand noch, man darf kein Winzip zum Entpacken nehmen.

Gruß,
Happy

Verfasst: Mi 18. Jan 2006, 16:19
von ibbi
eber hat geschrieben:Diese Optionen nutze ich bereits aber gegen Bufferoverflows und Co helfen sie eigentlich auch nicht.
Die sind für den Compiler - außer in Ausnahmefällen - eigentlich nicht feststellbar. That's C.

Verfasst: Mi 18. Jan 2006, 16:24
von ibbi
jk hat geschrieben:es gibt doch irgendwo die scriptsammlung zum bau des cross-gcc unter linux für den topf
Es stellt sich nur die Frage, ob bzw. welche Anpassungen Topfield am gcc noch vorgenommen hat, was sich mangels Quellcode ja nicht feststellen lässt.

Verfasst: Mi 18. Jan 2006, 16:29
von ibbi
eber hat geschrieben:-fbounds-check
Mal schnell gegoogelt:

For front-ends that support it, generate additional code to check that indices used to access arrays are within the declared range. This is currently only supported by the Java and Fortran 77 front-ends.

Wie gesagt, C ist C.

Verfasst: Mi 18. Jan 2006, 16:40
von DeJe
Habe es mal eingebastelt.
Aber scheinbar will er nicht so richtig. :(
Entpacken konnte ich schon alles.

Dann aber Fehler beim Übersetzen des Taptest:
"D:\Topfield\Toolchain\taptest>mips-gcc.exe -O2 -c -mlong-calls -msoft-float -mqn
xpic -fno-delayed-branch -I D:\Topfield\TAP\Include -I C:\cygwin\usr\local\topfi
eld-gcc\include -I C:\CYGWIN\INCLUDE simple.c
mips-gcc: installation problem, cannot exec `as': No such file or directory"

Verfasst: Mi 18. Jan 2006, 17:41
von hagge
Achtung, hier eine kleine Warnung von mir!

Einen GCC für Crosscompilierung zu übersetzen und zu installieren ist leider nicht ganz trivial. Das Problem ist, dass im Standard-GCC-Archiv eben nicht alle Patches für die entsprechenden Targetarchitekturen drin sind, sondern meist nur für x86. Für PowerPC gibt es da eigene Webseiten, die alle PowerPC-Änderungen hosten, ebenso für ARM. Für MIPS wird es vermutlich ähnliches geben. Bevor man also loscompiliert, muss man erst mal diese Patches finden und anbringen.

Dann fängt alles damit an, dass man erst mal die Binutils als Crosstools zum Laufen kriegen muss. Dort ist nämlich der Assembler und Linker enthalten. Erst wenn das geklappt hat kann man den GCC konfigurieren und compilieren. Früher (GCC 2.x) musste man das sogar in zwei Schritten machen, erstmal mit der newlib und dann erst mit der glibc. Wie das in der Zwischenzeit seit GCC 3.x geht, weiß ich leider auch nicht genau, hab es seitdem nicht mehr gemacht, denn der GCC 3 war lange nicht Crosscompilerfähig, und so wurde noch lange Zeit der GCC 2.x für Crosscompilierung verwendet. Am Ende muss man noch die passende Library übersetzen, also üblicherweise die glibc. Die zu Installieren ist schon wieder eine Kunst für sich, weil dabei so Henne-Ei-Probleme auftreten und im Installationsschritt noch Anpassungen an der Library geschehen. Besonders da gibt es massiv Probleme, wenn man in einen anderen Pfad installieren will, als den, wo die Bibliotheken später liegen sollen.

Wenn man dabei beim Konfigurieren irgendwas falsch macht, dann kann es sein, dass beim Installationsschritt der rechnereigene GCC überschrieben wird. Noch fataler ist es, wenn man die glibc falsch installiert, dann zerschießt man sich nämlich die ganzen Systembibliotheken des PCs. Unter Linux kann das im Extremfall bedeuten, dass man das Linux komplett neu aufsetzen muss. Denn ohne Systembibliotheken läuft nicht mal ein ls-Kommando.

Also sollte sich nur jemand an diese Crosscompiler-Aufgabe machen, wenn er genau weiß, was er tut, was die Begriffe HOST- und TARGET-Architektur bedeuten, was der PREFIX ist, wie man etwas in einen anderen Installpath installiert und wie genau alles mit Systembibliotheken, Compiler, Binutils und all den andern Tools zusammenhängt.

Es ist machbar, aber bitte vorsichtig sein! Das System ist bei diesen Aktionen schnell zerschossen.

Gruß,

Hagge