C++ Compiler-Frage!
Steffen Röder
ich bin gerade erst neu Eingestiegen bei C++.
Gibt es eine Möglichkeit einen Programm das unter C++ geschrieben
wurde und zu einer *.exe-Compiliert wurde in den alten Zustand zurück zu
Compilieren,
so das man weiter an dem Programm arbeiten kann?
Oder vieleicht ein anders C++ Programm was man nicht selber geschrieben hat
im Entwicklermodus bearbeiten kann.
Danke
Steffen Röder
Lutz Donnerhacke
>Gibt es eine Möglichkeit einen Programm das unter C++ geschrieben
>wurde und zu einer *.exe-Compiliert wurde in den alten Zustand zurück zu
>Compilieren,
Für viele Compiler ist das möglich, weil diese Compiler schlechten Code
erzeugen oder noch Debugging Informationen drin haben.
Gregor Fabritius
aber selbst aus debugging informationen kriegst du doch keinen kompletten
sauberen c++ code wieder hin, oder!? das sind IMHO höchstens ein paar
informationen mehr, die aus dem maschinencode noch ein paar variablennamen
erkennen lassen.
gregor
Lutz Donnerhacke
Moderne Codegeneratoren sind schlecht genug, um den Source trivial zu
rekonstruieren. Variablennamen aus den Debugging Infos.
Lutz Donnerhacke
>Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>> Moderne Codegeneratoren sind schlecht genug, um den Source trivial zu
>> rekonstruieren. Variablennamen aus den Debugging Infos.
>
>Du kannst etwas dem ursprünglichen Quellcode funktionell ähnliches
>(hoffentlich äquivalentes) rekonstruieren, aber genau den Quellcode
>kriegst du nur natürlich nicht, schon weil die Kommentare fehlen.
Korrekt. Meistens ist der Output des Recompilers besser lesbar als das
Original.
Felix von Leitner
> Moderne Codegeneratoren sind schlecht genug, um den Source trivial zu
> rekonstruieren. Variablennamen aus den Debugging Infos.
Nein.
Du kannst etwas dem ursprünglichen Quellcode funktionell ähnliches
(hoffentlich äquivalentes) rekonstruieren, aber genau den Quellcode
kriegst du nur natürlich nicht, schon weil die Kommentare fehlen.
Felix
--
"when the disc is run as root, be sure to type in xhost + in the
console prior to launch Sun Solutions"
Holger Veit
Felix von Leitner <usenet-...@fefe.de> wrote:
>Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>> Moderne Codegeneratoren sind schlecht genug, um den Source trivial zu
>> rekonstruieren. Variablennamen aus den Debugging Infos.
>
>Nein.
>Du kannst etwas dem ursprünglichen Quellcode funktionell ähnliches
>(hoffentlich äquivalentes) rekonstruieren, aber genau den Quellcode
>kriegst du nur natürlich nicht, schon weil die Kommentare fehlen.
Die Funktion ist das Relevante bei Quellcode, nicht die Form. Die Funktion
ist, bei CISC-Prozessoren wie dem i386 mit solchen recht einfallslosen
Compileren wie dem gcc ueberraschend gut regenerierbar. Ob die Schleifen-
variable dann z.B. 'i' heisst oder
'dies_ist_ein_langer_name_zum_aergern_des_decompilierers',
ist wurscht.
Holger
--
begin LOVE-LETTER-FOR-YOU.txt.vbs
You are using dangerous junk software which will arbitrarily interpret
fully valid text. Get rid of this garbage and use correctly working software.
end
Hans Bonfigt
>
> Korrekt. Meistens ist der Output des Recompilers besser lesbar als das
> Original.
Vielleicht sogar 'richtiger':
Aus
...
ival=<wert>;
...
rc=setjmp(stackcontext);
if (rc==0) { /* 'ival' wird nicht referiert */
...
}
else {
...
}
...
func(ival);
...
machte mein Compiler unlaengst:
...
rc=setjmp(stackcontext);
if (rc==0) {
...
}
else {
...
}
...
i=<val>;
func(ival);
...
Ein Recompiler waere mir gelegen gekommen.
Gruss,
--
Hans Bonfigt /SES/
UNIX App. Development Systementwicklung Schollmeier
Phone: +49 171 3758928 <bonfigt....@t-online.de>
Felix von Leitner
> Die Funktion ist das Relevante bei Quellcode, nicht die Form.
Natürlich.
Die Frage war aber nicht, ob du das Relevante wiederherstellen kannst,
sondern "das Programm", und darunter verstehen Leute heute halt den
kompletten Quellcode.
> Die Funktion ist, bei CISC-Prozessoren wie dem i386 mit solchen recht
> einfallslosen Compileren wie dem gcc ueberraschend gut regenerierbar.
> Ob die Schleifen- variable dann z.B. 'i' heisst oder
> 'dies_ist_ein_langer_name_zum_aergern_des_decompilierers', ist
> wurscht.
Das kommt darauf an.
Wenn deine Programme alle ohne Kommentare und sprechende Funktions- und
Variablennamen offensichtlich sind, dann beglückwünsche ich dich. Ich
bin bisher noch nicht einmal so weit, daß alle von mir formulierten
Algorithmen sogar mit sprechenden Namen verständlich sind, ohne daß ich
sie kommentiere.
Ich will mal so sagen: natürlich kann man das verstehen, wenn man viel
Zeit investiert. Aber dafür muß man daraus keinen C-Code dekompilieren,
dann kann man sich auch gleich den Maschinencode angucken.
Felix
--
Researcher Roger Short of the Royal Women's Hospital in Melbourne,
Australia, has hatched a plan to grow human sperm in mice using tissue
transplanted from humans. [Ed: No sense in letting universal revulsion
stand in the way of science.] --Feb 1 1998 THIS is TRUE
Lutz Donnerhacke
>Lutz Donnerhacke:
>> Korrekt. Meistens ist der Output des Recompilers besser lesbar als das
>> Original.
>
>Vielleicht sogar 'richtiger':
Nein, nur 'angemessener'.
> ...
> ival=<wert>;
> ...
> rc=setjmp(stackcontext);
> if (rc==0) { /* 'ival' wird nicht referiert */
> ...
> }
> else {
> ...
> }
> ...
> func(ival);
> ...
>
>
>machte mein Compiler unlaengst:
>
> ...
> rc=setjmp(stackcontext);
> if (rc==0) {
> ...
> }
> else {
> ...
> }
> ...
> i=<val>;
> func(ival);
> ...
Schenke dem Compilerhersteller das Drachenbuch.
Felix von Leitner
> ...
> ival=<wert>;
> ...
> rc=setjmp(stackcontext);
> if (rc==0) { /* 'ival' wird nicht referiert */
> ...
> }
> else {
> ...
> }
> ...
> func(ival);
> ...
>
>
> machte mein Compiler unlaengst:
>
> ...
> rc=setjmp(stackcontext);
> if (rc==0) {
> ...
> }
> else {
> ...
> }
> ...
> i=<val>;
> func(ival);
> ...
Hoffentlich machte er wenigstens "ival=<val>" daraus...?
> Ein Recompiler waere mir gelegen gekommen.
gdb ist dein Freund.
Felix
Hans Bonfigt
>
> Hoffentlich machte er wenigstens "ival=<val>" daraus...?
ival=<wert>; so wie im ersten Listing angegeben. Copy & Paste
waere mein Freund gewesen.
> > Ein Recompiler waere mir gelegen gekommen.
>
> gdb ist dein Freund.
Ich habe sogar einen graphischen Debugger, aber anstaendige Menschen
kommen mit 'printf()' ueber die Runden oder gucken sich den generier-
ten Assemblercode an. Ganz im Ernst: Die Bedienung dieses Superteils
ist so kompliziert, dass ich irgendwann einmal aufgesteckt habe.
Speziell von _Dir_ hette ich die haemische Frage erwartet, warum in
aller Welt die Umstellung von 'ival=<wert>' direkt vor die Zeile mit
der ersten Verwendung Probleme bereitet hat, und um sie vorwegzuneh-
men: Ja, es befand sich ein 'goto' im Block fuer die 'setjmp()' -
Auswertung.
Dietz Proepper
>* Felix von Leitner wrote:
>>Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>>> Moderne Codegeneratoren sind schlecht genug, um den Source trivial zu
>>> rekonstruieren. Variablennamen aus den Debugging Infos.
>>
>>Nein.
>>Du kannst etwas dem ursprünglichen Quellcode funktionell ähnliches
>>(hoffentlich äquivalentes) rekonstruieren, aber genau den Quellcode
>>kriegst du nur natürlich nicht, schon weil die Kommentare fehlen.
>
>Original.
Naja, der Compiler optimiert wesentlich monotoner auf eine Normalform
als jeder mir bekannte Programmierer. Ist irgendwo sein Job ;)
Und, um auf das Thema "schlechte Codegeneratoren" zurückzukommen, so
schlecht können sie nicht sein wenn der Output des Recompilers usw.
~dietz
--
Dietz Proepper
>Ich habe sogar einen graphischen Debugger, aber anstaendige Menschen
Du auch? Ich muß ehrlich zugeben, wenn ich ihn nicht habe dann fühle
ich mich einsam.
>kommen mit 'printf()' ueber die Runden oder gucken sich den generier-
Ja, sicher. Wenn wir wollen geben wir unsere Nybbles auch via Schalter
ein. Das wollen wir aber nicht.
>ten Assemblercode an. Ganz im Ernst: Die Bedienung dieses Superteils
*bäh*! Komm Hans, wie oft hast Du in der Situation versucht, was
zu komplexes zu verstehen und bist damit auf die Nase gefallen? Am
Schluß hat man n Seiten an Papier mit händischen traces
vollgeschrieben und muß dann doch zum Tool zurück? Oder printfs?
Nee, da ist mir meist der Debugger lieber.
>ist so kompliziert, dass ich irgendwann einmal aufgesteckt habe.
*g* Du benötigst 10%, Du kennst 30%. Wo ist das Problem?
~dietz
Stefan Froehlich
>>Korrekt. Meistens ist der Output des Recompilers besser lesbar als das
>>Original.
> Naja, der Compiler optimiert wesentlich monotoner auf eine Normalform
> als jeder mir bekannte Programmierer. Ist irgendwo sein Job ;)
Ach, das haengt auch vom Compiler ab und sollte nicht so verallgemeinert
werden. Ich entwickle gerade eine Art Compiler, der hochoptimierten Code
fuer Spezialprozessoren (DSPs) erzeugt, indem er einen Zufallsgenerator
anwirft und die besten Loesungen genetisch ausmustert. Das Ding ist, soweit
man es bis jetzt beurteilen kann, ausgesprochen effektiv, aber der Code,
der hinten herauskommt dafuer ein wenig... aeh, eigenwillig.
Servus,
Stefan
--
Stefan - Welch ein Gefuehl!
(http://www.sloganizer.de/)
Holger Groch
>
> Ach, das haengt auch vom Compiler ab und sollte nicht so verallgemeinert
> werden. Ich entwickle gerade eine Art Compiler, der hochoptimierten Code
> fuer Spezialprozessoren (DSPs) erzeugt, indem er einen Zufallsgenerator
> anwirft und die besten Loesungen genetisch ausmustert. Das Ding ist, soweit
> man es bis jetzt beurteilen kann, ausgesprochen effektiv, aber der Code,
> der hinten herauskommt dafuer ein wenig... aeh, eigenwillig.
>
Schlimmer als der Output vom gcc fuer den ADSP218X kann es nicht werden.
Mit Hinkucken und Wegkucken kann man dessen Output um Faktor 5-10
schneller werden lassen. Von der Groesse ganz zu schweigen.
Lutz Donnerhacke
>Schlimmer als der Output vom gcc fuer den ADSP218X kann es nicht werden.
gcc erzeugt fast immer den denkbar schlechtesten Code. Das Verfahren Deines
Vorredners wurde angewand, um den Output eines nativen hochoptimierenden und
hochgelobten C-Compilers für einen DSP nachzubearbeiten. Ergebnis war ein um
20% kürzerer und 40% schnellerer Code.
Stefan Froehlich
>> Das Ding ist, soweit man es bis jetzt beurteilen kann, ausgesprochen
>> effektiv, aber der Code, der hinten herauskommt dafuer ein wenig... aeh,
>> eigenwillig.
> Schlimmer als der Output vom gcc fuer den ADSP218X kann es nicht werden.
> Mit Hinkucken und Wegkucken kann man dessen Output um Faktor 5-10
> schneller werden lassen. Von der Groesse ganz zu schweigen.
Keine Frage... da stecken aber auch ganz andere Zielsetzungen dahinter.
Ich schrieb "eine Art Compiler" deswegen, weil der Input keine Hochsprache
ist, sondern lediglich Gleichungssysteme. Dafuer ist der Output insoferne
recht gut optimiert, als dass ich je nach Problemstellung null bis einige
wenige Assemblerzeilen von der optimalen Loesung entfernt bin. Wir reden
von Prozent und nicht von Faktoren :-)
Servus,
Stefan
--
Im siebten Himmel. Mit Stefan. Ein beschwipstes Vergnuegen!
(http://www.sloganizer.de/)
Lutz Donnerhacke
>Hans Bonfigt wrote:
>>kommen mit 'printf()' ueber die Runden oder gucken sich den generier-
>
>Ja, sicher. Wenn wir wollen geben wir unsere Nybbles auch via Schalter
>ein. Das wollen wir aber nicht.
Doch, genau das will man. Damit kann man beim fertigen Produkt einen
Debugmodus so aktivieren, daß der Endkunde sich selbst helfen kann oder
zumindest Ergebnisse zeigen kann, die Support überhaupt erst gestatten.
(Leidvolle gestrige Kundenerfahrung mit .../linux/drivers/net/ne.c)
(Leidvolle eigne Erfahrung mit .../linux/drivers/net/wavelan.c)
gdb ist unbedienbar, zeigt falsche Ergebnisse und findet keine Compilerfehler.
Compilerfehler sind die, die Hans beschrieben hat. Mit -g werden zusätzliche
Inspection Points eingefügt, die den fehlerhaften Optimierschritt nicht
gestatten. Dazu gibt es einen ganzen Abschnitt im Drachenbuch Kapitel 10 und
im Ada95 Reference Manual.
Holger Groch
>
> ... Dafuer ist der Output insoferne
> recht gut optimiert, als dass ich je nach Problemstellung null bis einige
> wenige Assemblerzeilen von der optimalen Loesung entfernt bin. Wir reden
> von Prozent und nicht von Faktoren :-)
>
Das klingt ja wirklich sehr gut. Bei "null bis einige" wuerde ich nichts
mehr anfassen und alles so lassen wie es ist. :-)
Fuer Rueckuebersetzer allerdings schlechte Karten.
Lutz Donnerhacke
>Lutz Donnerhacke schrieb:
>> * Holger Groch wrote:
>> >Schlimmer als der Output vom gcc fuer den ADSP218X kann es nicht werden.
>>
>> Vorredners wurde angewand, um den Output eines nativen hochoptimierenden und
>> hochgelobten C-Compilers für einen DSP nachzubearbeiten. Ergebnis war ein um
>> 20% kürzerer und 40% schnellerer Code.
>
>aber auch nicht leicht.
Stimmt, aber die höchst eigenwillige Architektur des x86 ist noch schlimmer.
Da GCC für eine homogene Registerarchitektur entworfen wurde (besonders die
Flußgraphenmanipulation und der Codegenerator dort speziell der Register-
allocator) ist das Ergebnis vorhersagbar beschissen.
Holger Groch
Christian Leber
>>Ja, sicher. Wenn wir wollen geben wir unsere Nybbles auch via Schalter
>>ein. Das wollen wir aber nicht.
>Doch, genau das will man. Damit kann man beim fertigen Produkt einen
>Debugmodus so aktivieren, daß der Endkunde sich selbst helfen kann oder
>zumindest Ergebnisse zeigen kann, die Support überhaupt erst gestatten.
http://www-scf.usc.edu/~moissetd/betterc/
Ich hab bis jetzt nur die Doku gelesen, aber das ganze wirkt ganz
interessant. (steht unter der LGPL)
Aber bis jetzt hab ich eigentlich alle schlimmen Bugs in meinen
Prograemmlein mit yamd und ddd/gdb gefunden, aber es ist nicht wirklich
effektiv mit dem ddd Zeile fuer Zeile ein Programm durchzugehen.
Christian Leber
--
ICQ: 13004455
Lutz Donnerhacke
>Am 25 May 2000 07:40:41 GMT, meinte lu...@iks-jena.de (Lutz Donnerhacke)
>>>Ja, sicher. Wenn wir wollen geben wir unsere Nybbles auch via Schalter
>>>ein. Das wollen wir aber nicht.
>>Doch, genau das will man. Damit kann man beim fertigen Produkt einen
>>Debugmodus so aktivieren, daß der Endkunde sich selbst helfen kann oder
>>zumindest Ergebnisse zeigen kann, die Support überhaupt erst gestatten.
>
>http://www-scf.usc.edu/~moissetd/betterc/
>Ich hab bis jetzt nur die Doku gelesen, aber das ganze wirkt ganz
>interessant. (steht unter der LGPL)
Er soll zu Ada wechseln, da hat er alles, was er haben will, und zusätzlich
kann es der Compiler sogar noch nutzen. Sein Ansatz scheitert an der
Unfähigkeit von C.
>Aber bis jetzt hab ich eigentlich alle schlimmen Bugs in meinen
>Prograemmlein mit yamd und ddd/gdb gefunden, aber es ist nicht wirklich
>effektiv mit dem ddd Zeile fuer Zeile ein Programm durchzugehen.
Ich habe bisher nur sehr triviale Fehler mit einem Debugger gefunden. An
geeigneten Stellen asserts und if debug and localmask then Log ... sind da
wesentlich nützlicher. Besonders, wenn es irgendwelche irgendwo laufenden
Daemons sind.
Ricardo Suarez
>
> * Christian Leber wrote:
> >Am 25 May 2000 07:40:41 GMT, meinte lu...@iks-jena.de (Lutz Donnerhacke)
> >>>Ja, sicher. Wenn wir wollen geben wir unsere Nybbles auch via Schalter
> >>>ein. Das wollen wir aber nicht.
> >>Doch, genau das will man. Damit kann man beim fertigen Produkt einen
> >>Debugmodus so aktivieren, daß der Endkunde sich selbst helfen kann oder
> >>zumindest Ergebnisse zeigen kann, die Support überhaupt erst gestatten.
> >
> >http://www-scf.usc.edu/~moissetd/betterc/
> >Ich hab bis jetzt nur die Doku gelesen, aber das ganze wirkt ganz
> >interessant. (steht unter der LGPL)
>
> Er soll zu Ada wechseln, da hat er alles, was er haben will, und zusätzlich
> kann es der Compiler sogar noch nutzen. Sein Ansatz scheitert an der
> Unfähigkeit von C.
Nicht C sondern der Entwickler ist unfähig.
Ricardo
--
Auch das Chaos gruppiert sich um
einen festen Punkt, sonst wäre es
nicht einmal als Chaos da.
-Arthur Schnitzler
Lutz Donnerhacke
>Lutz Donnerhacke schrieb:
>> Er soll zu Ada wechseln, da hat er alles, was er haben will, und zusätzlich
>> kann es der Compiler sogar noch nutzen. Sein Ansatz scheitert an der
>> Unfähigkeit von C.
>
>Nicht C sondern der Entwickler ist unfähig.
Nein, er will weiter in Eiffel schreiben. Das ist vernünftig.
Felix von Leitner
> Ich habe sogar einen graphischen Debugger, aber anstaendige Menschen
Ich finde gdb nur für das Debuggen auf Assemblerebene umständlich zu
bedienen, aber auch das kann man damit machen, wenn man sich an die
Syntax mal gewöhnt hat.
(gdb) x/10c 0x80484b4
Felix
Felix von Leitner
> >Ich habe sogar einen graphischen Debugger, aber anstaendige Menschen
> ich mich einsam.
Ich habe mal ddd versucht, bin aber davon schnell wieder abgekommen.
Ich bin damit schlicht nicht so effizient wie mit gdb.
> >kommen mit 'printf()' ueber die Runden oder gucken sich den generier-
> Ja, sicher. Wenn wir wollen geben wir unsere Nybbles auch via Schalter
> ein. Das wollen wir aber nicht.
Never underestimate the power of printf for debugging.
Bei komplexeren Anwendungen mit mehreren Threads oder Prozessen benutze
ich das heute noch, wenn ich mir einen Überblick verschaffen will.
> >ten Assemblercode an. Ganz im Ernst: Die Bedienung dieses Superteils
> *bäh*! Komm Hans, wie oft hast Du in der Situation versucht, was
> zu komplexes zu verstehen und bist damit auf die Nase gefallen?
Manchmal muß man eben.
Ich sage nur "Interpreter crack". ;-)
Schwärm... LucasArts...
Felix
--
After the year 2015, there will be no airplane crashes.
There will be no takeoffs either, because electronics will
occupy 100 percent of every airplane's weight.
--Norman R. Augustine
Felix von Leitner
> gdb ist unbedienbar, zeigt falsche Ergebnisse und findet keine Compilerfehler.
gdb ist in der Bedienung wie Unix. Wenn man sich daran gewöhnt hat, mag
man es nicht missen.
Das mit den falschen Ergebnissen kann ich nicht bestätigen. gdb tut
genau, was man ihm sagt. Nur können sich manche gdb gegenüber halt
nicht sonderlich gut artikulieren.
Und wenn du von gdb erwartet hast, daß er Fehler findet (egal ob deine
oder die des Compilers), dann hast du da massiv was falsch verstanden.
> Compilerfehler sind die, die Hans beschrieben hat.
Hans hat nicht beschrieben, sondern skizziert. Seine Skizze erlaubt den
zweifelsfreien Rückschluß auf einen Compilerfehler nicht.
> Mit -g werden zusätzliche Inspection Points eingefügt, die den
> fehlerhaften Optimierschritt nicht gestatten.
Das hängt davon ab, welcher Optimierschritt fehlerhaft ist.
Felix
--
What is this talk of "release?" We do not make software "releases." Our
software "escapes" leaving a bloody trail of designers and quality
assurance people in its wake.
--Moncr...@gvl.esys.com, as seen on the on the PerlTK mailing list
Lutz Donnerhacke
>> gdb ist unbedienbar, zeigt falsche Ergebnisse und findet keine
>> Compilerfehler.
>
>gdb ist in der Bedienung wie Unix. Wenn man sich daran gewöhnt hat, mag
>man es nicht missen.
Ich wüßte z.B. ab und zu gern, was ich gerade debugge. Mein Code ist
besonders in größeren Projekten nicht darauf ausgelegt, in einer einzelnen
Zeile den kompletten Context anzuzeigen.
Ich würde gerne die Liste der aktiven Variablen einsehen und auf deren
Änderungen aufmerksam gemacht werden. Ich würde auch gerne einen Ausdruck in
meinem Code mal schnell mit dem aktuellen Variablenstand evaluieren lassen.
>Das mit den falschen Ergebnissen kann ich nicht bestätigen. gdb tut
>genau, was man ihm sagt. Nur können sich manche gdb gegenüber halt
>nicht sonderlich gut artikulieren.
Ich möchte meine Programme debuggen und nicht gdbs unbrauchbares
Eingabeinterface.
>Und wenn du von gdb erwartet hast, daß er Fehler findet (egal ob deine
>oder die des Compilers), dann hast du da massiv was falsch verstanden.
Mag sein das Du den gdb als Textadventure verstehst, aber ich verwende
Debugger in der Tat für die Fehlersuche.
>> Compilerfehler sind die, die Hans beschrieben hat.
>
>Hans hat nicht beschrieben, sondern skizziert. Seine Skizze erlaubt den
>zweifelsfreien Rückschluß auf einen Compilerfehler nicht.
Wer hat denn die Definition verschoben? Wer hat denn die Nebenwirkungen der
Funktion setjmp ignoriert? Wer hat denn fehlerhafte Flußdiagramme intern
erzeugt?
>> Mit -g werden zusätzliche Inspection Points eingefügt, die den
>> fehlerhaften Optimierschritt nicht gestatten.
>
>Das hängt davon ab, welcher Optimierschritt fehlerhaft ist.
Richtig. Allein diese Aussage macht den Debugger inakzetabel.
Ricardo Suarez
Stimmt auch nicht, am liebsten würde er in universal-Volltext
entwickeln.
So nach dem Motto: Deklariere eine Variable blablabla... - und
die Entwicklungsumgebung macht. Und JA, ich kenne Logo und Prolog.
Holger Veit
[...]
>Stimmt auch nicht, am liebsten würde er in universal-Volltext
>entwickeln.
>So nach dem Motto: Deklariere eine Variable blablabla... - und
>die Entwicklungsumgebung macht. Und JA, ich kenne Logo und Prolog.
Das ist wohl eher der Mythos von COBOL:
MULTIPLY FOO BY BAR GIVING SOMERESULT.
Mit dem Punkt am Ende, wie es sich fuer einen ordentlichen englischsprachigen
Satz gehoert. Manager, kauft diese tolle, neue Entwicklung von I**:
programmieren, wie man spricht, und ab jetzt verstehen Sie auch, was Ihre
Codierer den ganzen Tag treiben und koennen Sie sofort auf Fehler hinweisen,
da alles korrekter Text ist. Eine Revolution modernster Kalkulationstechnik,
das Konzept der Zukunft schlechthin.
Holger
P.S.: I** war schon immer _weg_weisend.
P.P.S.: Aber wohin weg, ausser in die Tonne, haben sie nicht verraten.
Felix von Leitner
> Schlimmer als der Output vom gcc fuer den ADSP218X kann es nicht werden.
> schneller werden lassen. Von der Groesse ganz zu schweigen.
Nun hört doch alle mal mit dem Winseln auf!
*groan*
Die Architektur von gcc ist halt auf RISC-Prozessoren ausgerichtet. Daß
der x86-Code nur mit vielen Kludges halbwegs konkurrenzfähig ist und daß
damit SIMD nicht gut abbildbar ist, ist klar. Wem das nicht gefällt,
der soll halt eine Alternative schaffen. So funktioniert freie
Software.
Im Übrigen wird das vielleicht besser, wenn die xa64-Leute ihren Code
integrieren.
Felix
--
"Den groessten Schlag gegen die organisierte Kriminalitaet koennte man
IMHO machen, indem man den BND aufloest und die CSU verbietet."
--Bernd Paysan
Dietz Proepper
>* Dietz Proepper wrote:
>>Hans Bonfigt wrote:
>>
>>Ja, sicher. Wenn wir wollen geben wir unsere Nybbles auch via Schalter
>>ein. Das wollen wir aber nicht.
>
Nein. Ich möchte wenn ich Software entwickle meistens doch ganz gerne eine
gewisse ->Abstraktion. Hierzu verwende ich ein ->Betriebssystem. Und
eine ->höhere Programmiersprache. Von unzähligen Tools gar nicht zu
reden. Daß man erwarten sollte daß sich Person auch ohne diese zu
helfen weiß ist eine ganz andere Sache.
>Debugmodus so aktivieren, daß der Endkunde sich selbst helfen kann oder
Wir sprachen von der Entwicklung. Meine Endkunden erwarten
normalerweise keine Wartungsluke sondern ->funktionierende
->Produkte. Die Wartungsluke baue ich zum reinen Selbstschutz ein. Du
willst garnicht genau wissen, wie schrecklich wenig Verständnis manche
Leute für schludrige Arbeit haben. Und denen ist es mit Verlaub
scheißegal, ob der Compiler, der Programmierer oder die Wesen vom
Hundsstern Mistgebaut haben.
>zumindest Ergebnisse zeigen kann, die Support überhaupt erst gestatten.
Deine Kunden lassen solche Spielchen mit sich machen? Du
Glücklicher. Meine machen bei sowas natürlich auch mit. Und berechnen
ihren Stundensatz für die Zeit die sie damit verplempert haben.
>(Leidvolle gestrige Kundenerfahrung mit .../linux/drivers/net/ne.c)
>(Leidvolle eigne Erfahrung mit .../linux/drivers/net/wavelan.c)
Und? Was lernen wir daraus? Besser, was hat das mit Debuggern
vs. printf zu tun?
>gdb ist unbedienbar, zeigt falsche Ergebnisse und findet keine Compilerfehler.
Ich verwende gdb alle Schaltjahre, kann also nicht allzuviel dazu
sagen. Wo Du Unbedienbarkeit siehst ist mir allerdings scheierhaft.
Was mich jetzt wirklich stutzig macht - bei gdb hast Du doch die
Wartungsluke - wie kann es sein daß er da falsche Ergebnisse anzeigt?
Erwartet hier gar wieder jemand "IBM" wo GNU 'draufsteht? Get real!
>Compilerfehler sind die, die Hans beschrieben hat. Mit -g werden zusätzliche
Und wie sollte der Debugger diese erkennen? Hmm, vielleicht sollte ich
mir neuer Tools zulegen, bei meinem Debugger wird davon ausgegangen
daß die Mustererkennung und Fehleranalyse *vor* dem Terminal sitzt.
Helfen tut der Debugger mir hier indem er z.B. parallel C-Sourcen und
Asm-Sequenzen zeigen kann. Wo man obige Fehler sehr schnell sieht. Und
sehr bald feststellt daß maximal 3% des Programmes in irgendeiner Form
zeitkritisch sind und an allen anderen Stellen der Optimizer einfach
zu riskant ist. Aber dazu hatte ich meine Meinung schon vor Monaten
geäußert.
>Inspection Points eingefügt, die den fehlerhaften Optimierschritt nicht
Gdb verhindert fehlerhafte Optimierung? Mir war bekannt daß etliche
Debugger ernsthafte Probleme mit dem Ergebnis hochgezüchteter
Optimizer haben aber daß der Debugger das Compilat verändert...
>gestatten. Dazu gibt es einen ganzen Abschnitt im Drachenbuch Kapitel 10 und
>im Ada95 Reference Manual.
Beide befinden sich nicht in meinem Besitz. Und, ganz ehrlich, mich
interessieren die Details des Optimizers reichlich wenig. Wenn ich
Grund zur Annahme habe daß der Optimizer funktioniert dann verwende
ich ihn. (Lies, wenn ich ausreichend starke Regressionstests habe dann
darf der Optimizer beweisen daß er taucht.) Leute die dergleichen
permanent verwenden haben imnsho nicht verstanden was man unter
defensiver Programmierung versteht.
Achja, für RISCante Architekturen gilt das was ich über Optimizer
gesagt habe nicht in der Form.
~dietz
--
Dietz Proepper
>Ich habe bisher nur sehr triviale Fehler mit einem Debugger gefunden. An
Dumme Frage, wie testest Du? Wie hoch ist die coverage? Mehr als 60%?
>geeigneten Stellen asserts und if debug and localmask then Log ... sind da
>wesentlich nützlicher. Besonders, wenn es irgendwelche irgendwo laufenden
Ich möchte auf keines von beiden verzichten.
>Daemons sind.
AttachToProcess. Oh. Geht das unter Linux überhaupt?
--
Lutz Donnerhacke
>Lutz Donnerhacke wrote:
>>zumindest Ergebnisse zeigen kann, die Support überhaupt erst gestatten.
>
>Deine Kunden lassen solche Spielchen mit sich machen? Du
>Glücklicher. Meine machen bei sowas natürlich auch mit. Und berechnen
>ihren Stundensatz für die Zeit die sie damit verplempert haben.
Das gilt auch umgekehrt. Mit der Aussage 'geht nicht' kann hier niemand
etwas anfangen. I.d.R. weist man dem Kunden Fehler nach.
>>(Leidvolle gestrige Kundenerfahrung mit .../linux/drivers/net/ne.c)
>>(Leidvolle eigne Erfahrung mit .../linux/drivers/net/wavelan.c)
>
>Und? Was lernen wir daraus? Besser, was hat das mit Debuggern
>vs. printf zu tun?
Ich bitte Dich, eine partiell defekte Netzkarte ohne Debugausgaben der
Hardwaretrieber korrekt zu dedektieren, wenn Du nichts weiter weißt, als daß
es einen Timeout gibt. Du weißt nicht, welchen Timeout, Du weißt nicht,
welche Aktionen funktionieren. Nimm ruhig den gdb für den Job. Ich ziege
kprintf vor.
>>gdb ist unbedienbar, zeigt falsche Ergebnisse und findet keine
>>Compilerfehler.
>
>Ich verwende gdb alle Schaltjahre, kann also nicht allzuviel dazu
>sagen. Wo Du Unbedienbarkeit siehst ist mir allerdings scheierhaft.
>
>Was mich jetzt wirklich stutzig macht - bei gdb hast Du doch die
>Wartungsluke - wie kann es sein daß er da falsche Ergebnisse anzeigt?
Um diese 'Wartungsluke' überhaupt öffnen zu können, muß Du vorher 'Bescheid
geben' (-g compilieren). Logisch, daß dann nicht der Produktionszustand zu
beobachten ist.
>>Compilerfehler sind die, die Hans beschrieben hat. Mit -g werden zusätzliche
>
>Und wie sollte der Debugger diese erkennen? Hmm, vielleicht sollte ich
>mir neuer Tools zulegen, bei meinem Debugger wird davon ausgegangen
>daß die Mustererkennung und Fehleranalyse *vor* dem Terminal sitzt.
Ein Compiler, der immer nur dann Fehler macht, wenn der Debugger nicht zum
Einsatz kommen soll, ist nicht untypisch. Diese Fehler zu finden bedarf
anderer Techniken als den Einsatz eines Debuggers. Deswegen habe ich mir die
Nutzung von Debuggern komplett abgewöhnt, es sei denn, ich bekomme
funktionierende Tools, wie z.B. unter vxWorks oder QNX. Ja selbst der
Debugger von Visual Studio ist brauchbar!
>Helfen tut der Debugger mir hier indem er z.B. parallel C-Sourcen und
>Asm-Sequenzen zeigen kann. Wo man obige Fehler sehr schnell sieht. Und
>sehr bald feststellt daß maximal 3% des Programmes in irgendeiner Form
>zeitkritisch sind und an allen anderen Stellen der Optimizer einfach
>zu riskant ist.
Semantik modifizierende Optimizer sind fehlerhaft. Da gibt es nichts zu
diskutieren. Allerdings ist das Nachweisen ein Problem.
Bitte sag mir, wie ich mit dem gdb parallel Quelle und Zielcode ansehe?
(Ich nutze dafür sonst immer -s und -d?)
>>Inspection Points eingefügt, die den fehlerhaften Optimierschritt nicht
>
>Gdb verhindert fehlerhafte Optimierung?
So er zum Einsatz kommen soll, ja.
>Mir war bekannt daß etliche Debugger ernsthafte Probleme mit dem Ergebnis
>hochgezüchteter Optimizer haben aber daß der Debugger das Compilat
>verändert...
Entweder Du kannst den Debugger anwenden oder Du hast Codefehler.
>>gestatten. Dazu gibt es einen ganzen Abschnitt im Drachenbuch Kapitel 10 und
>>im Ada95 Reference Manual.
>
>Beide befinden sich nicht in meinem Besitz.
Zumindest beim Buch entgeht Dir was. Das Reference Manual ohne etwas Praxis
zu lesen, ist nicht jedermanns Sache.
>Und, ganz ehrlich, mich interessieren die Details des Optimizers reichlich
>wenig. Wenn ich Grund zur Annahme habe daß der Optimizer funktioniert dann
>verwende ich ihn. (Lies, wenn ich ausreichend starke Regressionstests habe
>dann darf der Optimizer beweisen daß er taucht.)
Optimierer dürfen nicht durch diese Tests fallen. Das ist ein Grund für
Regreßforderungen.
>Leute die dergleichen permanent verwenden haben imnsho nicht verstanden was
>man unter defensiver Programmierung versteht.
Nein, viele Sprachen haben nicht die Möglichkeit, manschineneffiziente
Konstrukte überhaupt niederzuschreiben (C mit Pointeraritmethik, parallele
Befehle von DSPs). Das ist kein Mangel, sondern eine Folge der Abstraktion.
Elementare Optimizer sind dort notwendig, um sinnvolle Compilate zu
erzeugen. Dies gilt besonders für die funktionalen Sprachen.
Programmierung heißt eben nicht, daß alles in ASM gecoded wird.
Compiler, die fehlerhafte Optimizer enthalten, sind fehlerhaft. Wer damit
arbeitet, hat ein ernsthaftes Problem.
Ricardo Suarez
>
> On Thu, 25 May 2000 15:28:13 +0200, Ricardo Suarez <sua...@pdtec.de> wrote:
> [...]
> >Stimmt auch nicht, am liebsten würde er in universal-Volltext
> >entwickeln.
> >So nach dem Motto: Deklariere eine Variable blablabla... - und
> >die Entwicklungsumgebung macht. Und JA, ich kenne Logo und Prolog.
>
> Das ist wohl eher der Mythos von COBOL:
Eben.
> MULTIPLY FOO BY BAR GIVING SOMERESULT.
>
> Mit dem Punkt am Ende, wie es sich fuer einen ordentlichen englischsprachigen
> Satz gehoert. Manager, kauft diese tolle, neue Entwicklung von I**:
> programmieren, wie man spricht, und ab jetzt verstehen Sie auch, was Ihre
> Codierer den ganzen Tag treiben und koennen Sie sofort auf Fehler hinweisen,
> da alles korrekter Text ist. Eine Revolution modernster Kalkulationstechnik,
> das Konzept der Zukunft schlechthin.
Ach deswegen ist Cobol so grauenvoll - weil die Auftraggeber auch noch
mit-
sprechen - oh je.
> P.S.: I** war schon immer _weg_weisend.
Ja, _ab_weisend.
> P.P.S.: Aber wohin weg, ausser in die Tonne, haben sie nicht verraten.
Liegt es an meinem Verständnis oder gibt dieser Satz in der gestellten
Form nicht all-zu-viel Sinn.
Lutz Donnerhacke
>Lutz Donnerhacke wrote:
>
>Dumme Frage, wie testest Du?
Modulweise.
>Wie hoch ist die coverage? Mehr als 60%?
Ich bemühe mich drum, jede Anweisung in jedem Modul einmal ausgeführt zu
haben. Beim Zusammenbau wird diese Coverage dann nicht mehr erreicht.
>>geeigneten Stellen asserts und if debug and localmask then Log ... sind da
>>wesentlich nützlicher. Besonders, wenn es irgendwelche irgendwo laufenden
>
>Ich möchte auf keines von beiden verzichten.
Wozu dann noch Debugger?
>>Daemons sind.
>
>AttachToProcess. Oh. Geht das unter Linux überhaupt?
Ja, aber das will man nicht.
Holger Groch
>
> Holger Groch <hgr...@mail.master.de> wrote:
> > Schlimmer als der Output vom gcc fuer den ADSP218X kann es nicht werden.
> > Mit Hinkucken und Wegkucken kann man dessen Output um Faktor 5-10
> > schneller werden lassen. Von der Groesse ganz zu schweigen.
>
> Nun hört doch alle mal mit dem Winseln auf!
> *groan*
>
Von Winseln war nie die Rede. Ich nehme in dem Fall Assembler.
> Die Architektur von gcc ist halt auf RISC-Prozessoren ausgerichtet. Daß
> der x86-Code nur mit vielen Kludges halbwegs konkurrenzfähig ist und daß
> damit SIMD nicht gut abbildbar ist, ist klar. Wem das nicht gefällt,
> der soll halt eine Alternative schaffen. So funktioniert freie
> Software.
>
Trotzdem hat Analog Devices einen C-Compiler rausgetan der auf gcc
basiert.
Der war auch 'ne ganze Weile der einzige Verfuegbare.
IIRC wurden erst nachdem auf comp.dsp gemeckert wurde die Quellen
rausgetan.
(aber das ist eine andere Geschichte...)
Felix von Leitner
> Ich wüßte z.B. ab und zu gern, was ich gerade debugge.
(gdb) bt
gibt dir einen Stack Trace mit Angabe der Dateinamen. Wenn dir das
nicht reicht, kannst du auch
(gdb) info file
sagen und kriegst gesagt, welche Datei du gerade im Debugger hast.
> Mein Code ist besonders in größeren Projekten nicht darauf ausgelegt,
> in einer einzelnen Zeile den kompletten Context anzuzeigen.
(gdb) list
gibt dir Kontext.
> Ich würde gerne die Liste der aktiven Variablen einsehen und auf deren
> Änderungen aufmerksam gemacht werden.
Was sind aktive Variablen? Du meinst die zuletzt geänderten?
Über Änderungen der Variable i kannst du dich mit
(gdb) watch i
fortan informieren lassen.
> Ich würde auch gerne einen Ausdruck in meinem Code mal schnell mit dem
> aktuellen Variablenstand evaluieren lassen.
(gdb) p (i*3)
Cut-und-paste des Ausdrucks in deinem Code mußt du halt mit screen oder
deiner Maus machen.
> >Das mit den falschen Ergebnissen kann ich nicht bestätigen. gdb tut
> >genau, was man ihm sagt. Nur können sich manche gdb gegenüber halt
> >nicht sonderlich gut artikulieren.
> Ich möchte meine Programme debuggen und nicht gdbs unbrauchbares
> Eingabeinterface.
Wie gesagt, ist eine Frage der Gewöhnung.
Ich bin damit inzwischen sehr zufrieden. Neulich mußte ich mal einen
Buffer Overflow auf Assembler-Ebene debuggen, was ich vorher auch noch
nie mit gdb gemacht hatte, aber nach kurzem Blättern in der
Dokumentation klappte das hervorragend.
> >Und wenn du von gdb erwartet hast, daß er Fehler findet (egal ob deine
> >oder die des Compilers), dann hast du da massiv was falsch verstanden.
> Mag sein das Du den gdb als Textadventure verstehst, aber ich verwende
> Debugger in der Tat für die Fehlersuche.
Der Debugger ist kein Fehlersucher, sondern ein Werkzeug, mit dem _du_
Fehler suchen kannst.
Wenn es dir gelingt, ein Programm zu schreiben, das allgemein Fehler in
anderen Programmen erkennen kann, dann gebe ich dir ein Bier und die
Welt dir eine Turing-Medaille aus.
> >> Compilerfehler sind die, die Hans beschrieben hat.
> >Hans hat nicht beschrieben, sondern skizziert. Seine Skizze erlaubt den
> >zweifelsfreien Rückschluß auf einen Compilerfehler nicht.
> Wer hat denn die Definition verschoben? Wer hat denn die Nebenwirkungen der
> Funktion setjmp ignoriert? Wer hat denn fehlerhafte Flußdiagramme intern
> erzeugt?
Wer sagt denn, daß das fehlerhaft war? Da waren "..." dazwischen. Wenn
da z.B. ein goto drin war, war die Verschiebung durchaus gängig für das,
was man von einem Compiler erwartet, wenn man Optimierung anschaltet.
> >> Mit -g werden zusätzliche Inspection Points eingefügt, die den
> >> fehlerhaften Optimierschritt nicht gestatten.
> >Das hängt davon ab, welcher Optimierschritt fehlerhaft ist.
> Richtig. Allein diese Aussage macht den Debugger inakzetabel.
Das ist Problem des Compilers, nicht des Debuggers.
Wenn dein Debugger bei -g anderen Code erzeugt, dann ist er kaputt.
Felix
--
>I think it would be best if we all dropped the topic now and thought
>of more optimistic and delightful things :) Like fluffy bunnies,
>leaping across a field.......
..."It's comin' right for us!" *Blam* --Jason in alt.games.final-fantasy
Felix von Leitner
> Semantik modifizierende Optimizer sind fehlerhaft. Da gibt es nichts zu
> diskutieren. Allerdings ist das Nachweisen ein Problem.
Daher machen Compiler das auch nur, wenn du es ihnen explizit sagst.
Mit -O z.B.
Ich _erwarte_ von meinem Compiler sogar, daß er die Semantik ändert:
int i,j;
for (i=0; i<100; i++)
j=5;
sollte der Compiler z.B. nach
int i=100,j=5;
transformieren.
> Bitte sag mir, wie ich mit dem gdb parallel Quelle und Zielcode ansehe?
> (Ich nutze dafür sonst immer -s und -d?)
gdb zeigt bei mir immer den Quellcode an, und mit
(gdb) disassemble
kannst du dir den Zielcode angucken.
Felix
Lutz Donnerhacke
>> Semantik modifizierende Optimizer sind fehlerhaft. Da gibt es nichts zu
>> diskutieren. Allerdings ist das Nachweisen ein Problem.
>
>Daher machen Compiler das auch nur, wenn du es ihnen explizit sagst.
Semantik ändern? Nicht wirklich.
>Ich _erwarte_ von meinem Compiler sogar, daß er die Semantik ändert:
>
> int i,j;
> for (i=0; i<100; i++)
> j=5;
>
>sollte der Compiler z.B. nach
>
> int i=100,j=5;
>
>transformieren.
Das ist semantisch äquivalent.
>> Bitte sag mir, wie ich mit dem gdb parallel Quelle und Zielcode ansehe?
>> (Ich nutze dafür sonst immer -s und -d?)
>
>gdb zeigt bei mir immer den Quellcode an, und mit
>(gdb) disassemble
>kannst du dir den Zielcode angucken.
Das klappt nur für Demonstrationscode. Der ist kurz genug.
Lutz Donnerhacke
>
>(gdb) bt
>gibt dir einen Stack Trace mit Angabe der Dateinamen. Wenn dir das
>nicht reicht, kannst du auch
>
>(gdb) info file
>sagen und kriegst gesagt, welche Datei du gerade im Debugger hast.
>
>> Mein Code ist besonders in größeren Projekten nicht darauf ausgelegt,
>> in einer einzelnen Zeile den kompletten Context anzuzeigen.
>
>(gdb) list
>gibt dir Kontext.
Nicht wirklich. Ich möchte schon den Überblick behalten und nicht mein
Gedächtnis auffrischen, da der Überblick fehlt.
>> Ich würde gerne die Liste der aktiven Variablen einsehen und auf deren
>> Änderungen aufmerksam gemacht werden.
>
>Was sind aktive Variablen?
Im aktuellen Scope sichtbare.
>Du meinst die zuletzt geänderten? Über Änderungen der Variable i kannst du
>dich mit
>(gdb) watch i
>fortan informieren lassen.
Du weißt, was passiert, wenn man mehr als eine Funktion debuggen will?
>> Ich würde auch gerne einen Ausdruck in meinem Code mal schnell mit dem
>> aktuellen Variablenstand evaluieren lassen.
>
>(gdb) p (i*3)
>
>Cut-und-paste des Ausdrucks in deinem Code mußt du halt mit screen oder
>deiner Maus machen.
Ich habe schon Systeme gesehen, bei denen ich den Ausdruck im Quelltext nur
markieren mußte oder den Mauszeiger drauf liegen lassen mußte, um das zu
erhalten. Warum der Umstand?
>> Ich möchte meine Programme debuggen und nicht gdbs unbrauchbares
>> Eingabeinterface.
>
>Wie gesagt, ist eine Frage der Gewöhnung.
Auch emacs ist ein Frage der Gewöhnung. Mit der Zeit merkt man sich die
Paßworte, die die Funktionen freischalten.
>> >Und wenn du von gdb erwartet hast, daß er Fehler findet (egal ob deine
>> >oder die des Compilers), dann hast du da massiv was falsch verstanden.
>> Mag sein das Du den gdb als Textadventure verstehst, aber ich verwende
>> Debugger in der Tat für die Fehlersuche.
>
>Der Debugger ist kein Fehlersucher, sondern ein Werkzeug, mit dem _du_
>Fehler suchen kannst.
Ich ziehe Werkzeuge vor, die ich benutzen kann. gdb hält mich davon ab,
Fehler zu finden.
>Wenn es dir gelingt, ein Programm zu schreiben, das allgemein Fehler in
>anderen Programmen erkennen kann, dann gebe ich dir ein Bier und die
>Welt dir eine Turing-Medaille aus.
Du versuchst aktiv ein Mißverständnis zu provozieren. Schön, daß Du mir
zustimmst, daß gdb nicht geeignet ist, die von Dir genannte Aufgabe "Bei der
Fehlersuche behilflich zu sein" zu erfüllen.
>> Wer hat denn die Definition verschoben? Wer hat denn die Nebenwirkungen der
>> Funktion setjmp ignoriert? Wer hat denn fehlerhafte Flußdiagramme intern
>> erzeugt?
>
>Wer sagt denn, daß das fehlerhaft war? Da waren "..." dazwischen. Wenn
>da z.B. ein goto drin war, war die Verschiebung durchaus gängig für das,
>was man von einem Compiler erwartet, wenn man Optimierung anschaltet.
Ich halte Hans für fähig, keinen solchen Fall zu nehmen. Ausreden für
derartige Fehler können wir gerne suchen, wenn wir mehr Zeit haben.
>> >> Mit -g werden zusätzliche Inspection Points eingefügt, die den
>> >> fehlerhaften Optimierschritt nicht gestatten.
>> >Das hängt davon ab, welcher Optimierschritt fehlerhaft ist.
>> Richtig. Allein diese Aussage macht den Debugger inakzetabel.
>
>Das ist Problem des Compilers, nicht des Debuggers.
>Wenn dein Debugger bei -g anderen Code erzeugt, dann ist er kaputt.
Mein Compiler erzeugt bei -g anderen Code. Es ist ein gcc.
Dietz Proepper
>* Dietz Proepper wrote:
>>Lutz Donnerhacke wrote:
>>
>>Deine Kunden lassen solche Spielchen mit sich machen? Du
>>Glücklicher. Meine machen bei sowas natürlich auch mit. Und berechnen
>>ihren Stundensatz für die Zeit die sie damit verplempert haben.
>
>Das gilt auch umgekehrt. Mit der Aussage 'geht nicht' kann hier niemand
>etwas anfangen. I.d.R. weist man dem Kunden Fehler nach.
Selbstverfreilich ;).
>>>(Leidvolle gestrige Kundenerfahrung mit .../linux/drivers/net/ne.c)
>>>(Leidvolle eigne Erfahrung mit .../linux/drivers/net/wavelan.c)
>>
>>Und? Was lernen wir daraus? Besser, was hat das mit Debuggern
>>vs. printf zu tun?
>
>Ich bitte Dich, eine partiell defekte Netzkarte ohne Debugausgaben der
>Hardwaretrieber korrekt zu dedektieren, wenn Du nichts weiter weißt, als daß
>es einen Timeout gibt. Du weißt nicht, welchen Timeout, Du weißt nicht,
>welche Aktionen funktionieren. Nimm ruhig den gdb für den Job. Ich ziege
>kprintf vor.
Ack. Wobei mir bei vermuteter defekter Hardware in dem Preisbereich
der Schraubenzieher näher ist als jedliche Art von Debugger.
>>Was mich jetzt wirklich stutzig macht - bei gdb hast Du doch die
>>Wartungsluke - wie kann es sein daß er da falsche Ergebnisse anzeigt?
>
>Um diese 'Wartungsluke' überhaupt öffnen zu können, muß Du vorher 'Bescheid
>geben' (-g compilieren). Logisch, daß dann nicht der Produktionszustand zu
>beobachten ist.
Gut. ich hatte Dich richtig verstanden.
>>>Compilerfehler sind die, die Hans beschrieben hat. Mit -g werden zusätzliche
>>
>>Und wie sollte der Debugger diese erkennen? Hmm, vielleicht sollte ich
>>mir neuer Tools zulegen, bei meinem Debugger wird davon ausgegangen
>>daß die Mustererkennung und Fehleranalyse *vor* dem Terminal sitzt.
>
>Ein Compiler, der immer nur dann Fehler macht, wenn der Debugger nicht zum
>Einsatz kommen soll, ist nicht untypisch. Diese Fehler zu finden bedarf
Mein Reden.
>anderer Techniken als den Einsatz eines Debuggers. Deswegen habe ich mir die
>Nutzung von Debuggern komplett abgewöhnt, es sei denn, ich bekomme
Bei Eigenentwicklungen ziehe ich zunächst auch andere Techniken
vor. Z.B. Module die selbstständig die Korrektheit ihrer internen
Repräsentationen erkennen usw. Der Debugger ist nützlich wenn ich
z.B. Fehlerpfade testen möchte.
>funktionierende Tools, wie z.B. unter vxWorks oder QNX. Ja selbst der
>Debugger von Visual Studio ist brauchbar!
Der Debugger von Visual Studio ist definitiv brauchbar. Die anderen
beiden kenn' ich nicht.
>>Helfen tut der Debugger mir hier indem er z.B. parallel C-Sourcen und
>>Asm-Sequenzen zeigen kann. Wo man obige Fehler sehr schnell sieht. Und
>>sehr bald feststellt daß maximal 3% des Programmes in irgendeiner Form
>>zeitkritisch sind und an allen anderen Stellen der Optimizer einfach
>>zu riskant ist.
>
>Semantik modifizierende Optimizer sind fehlerhaft. Da gibt es nichts zu
>diskutieren. Allerdings ist das Nachweisen ein Problem.
Eigentlich sollte es doch so laufen daß die Korrektheit des Optimizers
bewiesen wird. Ja, ich weiß ich träume.
>Bitte sag mir, wie ich mit dem gdb parallel Quelle und Zielcode ansehe?
>(Ich nutze dafür sonst immer -s und -d?)
Wie gesagt, gdb verwende ich seltenst. Gut wenn das nicht geht ist das
ein echter Mangel.
>>>Inspection Points eingefügt, die den fehlerhaften Optimierschritt nicht
>>
>>Gdb verhindert fehlerhafte Optimierung?
>
>So er zum Einsatz kommen soll, ja.
;)
>>Mir war bekannt daß etliche Debugger ernsthafte Probleme mit dem Ergebnis
>>hochgezüchteter Optimizer haben aber daß der Debugger das Compilat
>>verändert...
>
>Entweder Du kannst den Debugger anwenden oder Du hast Codefehler.
Eben. Meine Rede gegen hochoptimierende Compiler.
>>>gestatten. Dazu gibt es einen ganzen Abschnitt im Drachenbuch Kapitel 10 und
>>>im Ada95 Reference Manual.
>>
>>Beide befinden sich nicht in meinem Besitz.
>
>Zumindest beim Buch entgeht Dir was. Das Reference Manual ohne etwas Praxis
>zu lesen, ist nicht jedermanns Sache.
Ack.
>>Und, ganz ehrlich, mich interessieren die Details des Optimizers reichlich
>>wenig. Wenn ich Grund zur Annahme habe daß der Optimizer funktioniert dann
>>verwende ich ihn. (Lies, wenn ich ausreichend starke Regressionstests habe
>>dann darf der Optimizer beweisen daß er taucht.)
>
>Optimierer dürfen nicht durch diese Tests fallen. Das ist ein Grund für
>Regreßforderungen.
Schon klar. Wobei ich immer das Zittern bekomme ist wenn irgendein
sogenannter Projektleiter 5 d vor der Release meint, so und jetzt
schalten wir mal die Optimierungen ein. Ohne ausreichend testen zu
können was da passiert. Die Steigerung ist dann ein "Aber es geht doch
alles", wenn man mal schnell 0.1% der Funktionalität "getestet" hat.
>>Leute die dergleichen permanent verwenden haben imnsho nicht verstanden was
>>man unter defensiver Programmierung versteht.
>
>Nein, viele Sprachen haben nicht die Möglichkeit, manschineneffiziente
>Konstrukte überhaupt niederzuschreiben (C mit Pointeraritmethik, parallele
>Befehle von DSPs). Das ist kein Mangel, sondern eine Folge der Abstraktion.
Ja, klar.
>Elementare Optimizer sind dort notwendig, um sinnvolle Compilate zu
>erzeugen. Dies gilt besonders für die funktionalen Sprachen.
Ebenfalls klar. Wobei es schon einen Unterschied macht, auf welcher
Ebene die Optimierung ansetzt. Manche Compiler sind so anständig,
manche Optimierungen als potentiell unsicher zu charakterisieren.
>Programmierung heißt eben nicht, daß alles in ASM gecoded wird.
Ach. Was Meister Knuth wohl dazu sagen würde ;).
>Compiler, die fehlerhafte Optimizer enthalten, sind fehlerhaft. Wer damit
>arbeitet, hat ein ernsthaftes Problem.
Wieviele Compiler kennst Du deren Optimierungsstufe nachweislich
fehlerfrei arbeitet? Ich bin an der Stelle leider ein gebranntes
Kind.
~dietz
--
Lutz Donnerhacke
>Lutz Donnerhacke wrote:
>>>>(Leidvolle gestrige Kundenerfahrung mit .../linux/drivers/net/ne.c)
>>>>(Leidvolle eigne Erfahrung mit .../linux/drivers/net/wavelan.c)
>>>
>>>Und? Was lernen wir daraus? Besser, was hat das mit Debuggern
>>>vs. printf zu tun?
>>
>>Ich bitte Dich, eine partiell defekte Netzkarte ohne Debugausgaben der
>>Hardwaretrieber korrekt zu dedektieren, wenn Du nichts weiter weißt, als daß
>>es einen Timeout gibt. Du weißt nicht, welchen Timeout, Du weißt nicht,
>>welche Aktionen funktionieren. Nimm ruhig den gdb für den Job. Ich ziege
>>kprintf vor.
>
>Ack. Wobei mir bei vermuteter defekter Hardware in dem Preisbereich
>der Schraubenzieher näher ist als jedliche Art von Debugger.
Be there, done that: Karte mit einem Chip, dessen Aufdruck mit einem 'Yes it
runs with Netware' übertüncht wurde.
>>anderer Techniken als den Einsatz eines Debuggers. Deswegen habe ich mir die
>>Nutzung von Debuggern komplett abgewöhnt, es sei denn, ich bekomme
>
>Bei Eigenentwicklungen ziehe ich zunächst auch andere Techniken
>vor. Z.B. Module die selbstständig die Korrektheit ihrer internen
>Repräsentationen erkennen usw. Der Debugger ist nützlich wenn ich
>z.B. Fehlerpfade testen möchte.
Richtig. Allerdings bekomme ich keinen Coredump (nur auf Wunsch) sondern
einen Exception-Dump. Und der steht im Logfile.
>>funktionierende Tools, wie z.B. unter vxWorks oder QNX. Ja selbst der
>>Debugger von Visual Studio ist brauchbar!
>
>Der Debugger von Visual Studio ist definitiv brauchbar. Die anderen
>beiden kenn' ich nicht.
Die anderen beiden tuen so, als ob Du neben dem Gerät stehst. Keine
Beeinträchtigung des Timings oder der Threads während des Debuggens. Alles
völlig klar und genauso, wie auf der Zielmaschine. Incl. der Maskenfehler
des Zielprozessors.
>>Semantik modifizierende Optimizer sind fehlerhaft. Da gibt es nichts zu
>>diskutieren. Allerdings ist das Nachweisen ein Problem.
>
>Eigentlich sollte es doch so laufen daß die Korrektheit des Optimizers
>bewiesen wird. Ja, ich weiß ich träume.
www.compilers.net/Research.html
gcc ist dort vermutlich unter "Runs everywhere, 'Nuff said." verzeichnet.
>>>Gdb verhindert fehlerhafte Optimierung?
>>
>>So er zum Einsatz kommen soll, ja.
>
>;)
In diversen Readmes von Software steht explizit drin, daß -g nicht
ausgeschaltet werden darf.
>>>Mir war bekannt daß etliche Debugger ernsthafte Probleme mit dem Ergebnis
>>>hochgezüchteter Optimizer haben aber daß der Debugger das Compilat
>>>verändert...
>>
>>Entweder Du kannst den Debugger anwenden oder Du hast Codefehler.
>
>Eben. Meine Rede gegen hochoptimierende Compiler.
Nein, gegen unzureichende Debugger.
>>Optimierer dürfen nicht durch diese Tests fallen. Das ist ein Grund für
>>Regreßforderungen.
>
>Schon klar. Wobei ich immer das Zittern bekomme ist wenn irgendein
>sogenannter Projektleiter 5 d vor der Release meint, so und jetzt
>schalten wir mal die Optimierungen ein. Ohne ausreichend testen zu
>können was da passiert. Die Steigerung ist dann ein "Aber es geht doch
>alles", wenn man mal schnell 0.1% der Funktionalität "getestet" hat.
Deswegen habe ich volle Optimierungseinstellung von Beginn an laufen.
Die globale Datenflußanalyse bringt einfach mehr Fehler zum Vorschein.
>>Elementare Optimizer sind dort notwendig, um sinnvolle Compilate zu
>>erzeugen. Dies gilt besonders für die funktionalen Sprachen.
>
>Ebenfalls klar. Wobei es schon einen Unterschied macht, auf welcher
>Ebene die Optimierung ansetzt. Manche Compiler sind so anständig,
>manche Optimierungen als potentiell unsicher zu charakterisieren.
Warum implementieren sie diese dann so fehlerhaft?
>>Programmierung heißt eben nicht, daß alles in ASM gecoded wird.
>
>Ach. Was Meister Knuth wohl dazu sagen würde ;).
Der erste Compiler (FORTRAN) hatte nur ein Designziel: Besseren oder
zumindest gleich guten Code zu erzeugen, wie die Handcoder. Das ist
mittlerweile dem Ziel gewichen, mehr Features in der Changelist zu haben als
andere.
Der erste Lisp-Interpreter wurde jahrelang nicht implementiert, weil er als
Teil eines Beweises schlicht nicht aufgefallen ist.
>>Compiler, die fehlerhafte Optimizer enthalten, sind fehlerhaft. Wer damit
>>arbeitet, hat ein ernsthaftes Problem.
>
>Wieviele Compiler kennst Du deren Optimierungsstufe nachweislich fehlerfrei
>arbeitet?
Für welche Sprachen? Für Occam gibt es einen IIRC.
Dietz Proepper
>* Dietz Proepper wrote:
>>Lutz Donnerhacke wrote:
>>
>>Dumme Frage, wie testest Du?
>
>Modulweise.
Ack.
>>Wie hoch ist die coverage? Mehr als 60%?
>
>Ich bemühe mich drum, jede Anweisung in jedem Modul einmal ausgeführt zu
>haben. Beim Zusammenbau wird diese Coverage dann nicht mehr erreicht.
Ack. Naja, hohe coverage modulübergreifend ist zumindest bei kleineren
Sachen oft nicht zwingend nötig.
>>>geeigneten Stellen asserts und if debug and localmask then Log ... sind da
>>>wesentlich nützlicher. Besonders, wenn es irgendwelche irgendwo laufenden
>>
>>Ich möchte auf keines von beiden verzichten.
>
>Wozu dann noch Debugger?
Damit ich z.B. auf die Schnelle Dinge die ich vorher vergessen habe
"anschauen" kann. Oder schwierig zu produzierende Situationen
simulieren kann, z.B. Fehlerpfade.
>>>Daemons sind.
>>
>>AttachToProcess. Oh. Geht das unter Linux überhaupt?
>
>Ja, aber das will man nicht.
Warum nicht? Aus meiner Sicht ergänzen sich gut gemachtes Logging und
eine Debugger glänzend. Das Logging erlaubt mir, viele Fälle einfach
zu analysieren und im Rest der Fälle gibt es gute Hinweise, wo der
erste breakpoint zu setzen ist.
~dietz
--
Hans Bonfigt
>
> > > Wer hat denn die Definition verschoben? Wer hat denn die
> > > Nebenwirkungen der Funktion setjmp ignoriert? Wer hat denn
> > > fehlerhafte Flußdiagramme intern erzeugt?
> > Wer sagt denn, daß das fehlerhaft war? Da waren "..." dazwischen.
> > Wenn da z.B. ein goto drin war, war die Verschiebung durchaus
> > gängig für das, was man von einem Compiler erwartet, wenn man
> > Optimierung anschaltet.
> Ich halte Hans für fähig, keinen solchen Fall zu nehmen. Ausreden für
> derartige Fehler können wir gerne suchen, wenn wir mehr Zeit haben.
Es befand sich in der Tat ein 'goto' im Auswertungsblock nach
'setjmp()'. Natuerlich habe ich ihn und natuerlich auch das Label
des Sprungzieles versuchsweise entfernt, das Resultat aber war das
gleiche.
Das Problem ist hier, dass der Compiler die speziellen Implikationen
von setjmp() nicht kennt. Er geht davon aus, dass alle lokalen Va-
riablen, von eventuellen Argumenten abgesehen, nicht referenziert
werden koennen. Faktisch aber wird in Falle von 'setjmp()' _jede_
lokale Variable referenziert.
Weil dem Compiler dieses Wissen fehlt, entscheidet er sich aus zwei
guten Gruenden, die Wertzuweisung zu verschieben. Das Schwein macht
reproduzierbar aus
status_var=<val>;
reason=setjmp(stack_context);
if (reason>0) do_err_handling_and_exit(reason,status_var);
reason=setjmp(stack_context);
if (reason>0) {
status_var=<val>;
do_err_handling_and_exit(reason,status_var);
}
respektive, wenn status_var nachfolgend nochmals referenziert wird:
reason=setjmp(stack_context);
status_var=<val>;
if (reason>0) do_err_handling_and_exit(reason,status_var);
Wenn ich nun die Frechheit besitze, 'status_var' im Hauptprogramm
zu modifizieren, z.B.
status_var=EVENT_ARRIVED;
rc=process_event(...);
und 'process_event()' resp. eine seiner Unterroutinen auf eine Aus-
nahmesituation z.B. mit 'lonjjmp(ENOSPC)' reagiert, habe ich ein
Problem, denn 'status_var' wird zunaechst mit einem - in diesem
Falle undefinierten - Wert ueberschrieben und nach Rueckkehr
ins Hauptprogramm nochmals, diesmal definiert falsch, zugewiesen.
Mein akutes Problem habe ich dadurch geloest, dass ich unter anderen
'status_var' _global_ definiert habe. Dann naemlich geht der Compi-
ler von der Annahme aus, dass _jede_ Funktion 'status_var' potentiell
referenzieren oder modifizieren koennte und wird sich bei der Ver-
schiebung der Wertzuweisung zurueckhalten. Aber das ist keine 'an-
staendige' Loesung.
Ich suche eher nach einer
#pragma HAS_KINKY_SIDE_EFFECTS
Direktive.
Nur IBM ist wieder 'mal fein 'raus:
$ cc -O3 dijdls.c -o dijdls
1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program. Please refer to documentation on -O3 and the
STRICT option for more information.
$
Gottseidank haben wir nicht allzuviele 'setjmp()' - Leichen im Keller,
aber ich werde sie alle durchsehen muessen, am Wochenende ...
Gruss,
--
Hans Bonfigt /SES/
UNIX App. Development Systementwicklung Schollmeier
Phone: +49 171 3758928 <bonfigt....@t-online.de>
Felix von Leitner
> >Ich _erwarte_ von meinem Compiler sogar, daß er die Semantik ändert:
> >
> > int i,j;
> > for (i=0; i<100; i++)
> > j=5;
> >
> >sollte der Compiler z.B. nach
> >
> > int i=100,j=5;
> >
> >transformieren.
> Das ist semantisch äquivalent.
Nicht, wenn du eine Interrupt-Routine hast, die annimmt, daß i auch mal
bei 80 vorbeikommt.
> >> Bitte sag mir, wie ich mit dem gdb parallel Quelle und Zielcode ansehe?
> >> (Ich nutze dafür sonst immer -s und -d?)
> >gdb zeigt bei mir immer den Quellcode an, und mit
> >(gdb) disassemble
> >kannst du dir den Zielcode angucken.
> Das klappt nur für Demonstrationscode. Der ist kurz genug.
Ich habe damit auch durchaus längere Funktionen untersucht.
Felix
Felix von Leitner
> >> Mein Code ist besonders in größeren Projekten nicht darauf ausgelegt,
> >> in einer einzelnen Zeile den kompletten Context anzuzeigen.
> >(gdb) list
> >gibt dir Kontext.
> Nicht wirklich. Ich möchte schon den Überblick behalten und nicht mein
> Gedächtnis auffrischen, da der Überblick fehlt.
Geschmacksfrage.
> >> Ich würde gerne die Liste der aktiven Variablen einsehen und auf deren
> >> Änderungen aufmerksam gemacht werden.
> >Was sind aktive Variablen?
> Im aktuellen Scope sichtbare.
Um Gottes Willen, das können Millionen sein, wenn du irgendwelche
obskuren 3rd-Party-Libraries dazulinkst. Beschränke dich lieber auf die
lokalen Variablen:
(gdb) info locals
Und wenn du unbedingt die statischen und globalen Variablen haben
willst, hilft
(gdb) info variables
(hab ich aber noch nie benutzt).
> Du weißt, was passiert, wenn man mehr als eine Funktion debuggen will?
Da der Prozessor gewöhnlich genau eine Funktion zur Zeit abarbeitet,
debuggt man gewöhnlich auch nur eine Funktion zur Zeit.
> >(gdb) p (i*3)
> >
> >Cut-und-paste des Ausdrucks in deinem Code mußt du halt mit screen oder
> >deiner Maus machen.
> Ich habe schon Systeme gesehen, bei denen ich den Ausdruck im Quelltext nur
> markieren mußte oder den Mauszeiger drauf liegen lassen mußte, um das zu
> erhalten. Warum der Umstand?
Mauszeiger liegen lassen ist langsamer als cut-und-paste.
> >Der Debugger ist kein Fehlersucher, sondern ein Werkzeug, mit dem _du_
> >Fehler suchen kannst.
> Ich ziehe Werkzeuge vor, die ich benutzen kann. gdb hält mich davon ab,
> Fehler zu finden.
Das liegt m.E. nicht an gdb. ;)
> Du versuchst aktiv ein Mißverständnis zu provozieren. Schön, daß Du mir
> zustimmst, daß gdb nicht geeignet ist, die von Dir genannte Aufgabe "Bei der
> Fehlersuche behilflich zu sein" zu erfüllen.
Ich stimme dir nicht zu.
Mir ist gdb ausgesprochen gut dabei behilflich.
Aber er findet Fehler halt nicht, das muß ich schon selber machen.
> >Das ist Problem des Compilers, nicht des Debuggers.
> >Wenn dein Debugger bei -g anderen Code erzeugt, dann ist er kaputt.
> Mein Compiler erzeugt bei -g anderen Code. Es ist ein gcc.
Ja und?
Das auf den Debugger zu schieben ist Verdrehung der Tatsachen.
Felix
Dietz Proepper
>Ich suche eher nach einer
>
>#pragma HAS_KINKY_SIDE_EFFECTS
>
>Direktive.
Je nach Compiler gibt es die. Der portable Weg ist die Verwendung des
type specifiers volatile.
~dietz
Dietz Proepper
>Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>> >Ich _erwarte_ von meinem Compiler sogar, daß er die Semantik ändert:
>> >
>> > int i,j;
>> > for (i=0; i<100; i++)
>> > j=5;
>> >
>> >sollte der Compiler z.B. nach
>> >
>> > int i=100,j=5;
>> >
>> >transformieren.
>> Das ist semantisch äquivalent.
>
>Nicht, wenn du eine Interrupt-Routine hast, die annimmt, daß i auch mal
>bei 80 vorbeikommt.
Dann such' in Deinem C-Manual nach volatile. Du Coder, Du ;)
~dietz
Dietz Proepper
>* Dietz Proepper wrote:
>>Ack. Wobei mir bei vermuteter defekter Hardware in dem Preisbereich
>>der Schraubenzieher näher ist als jedliche Art von Debugger.
>
>runs with Netware' übertüncht wurde.
*g* das ist dann *zu* billig.
>>Der Debugger von Visual Studio ist definitiv brauchbar. Die anderen
>>beiden kenn' ich nicht.
>
>Die anderen beiden tuen so, als ob Du neben dem Gerät stehst. Keine
>Beeinträchtigung des Timings oder der Threads während des Debuggens. Alles
>völlig klar und genauso, wie auf der Zielmaschine. Incl. der Maskenfehler
>des Zielprozessors.
Angeblich geht das mit dem MS-Debugger auch. Hab's aber noch nie life
gesehen.
>>Eigentlich sollte es doch so laufen daß die Korrektheit des Optimizers
>>bewiesen wird. Ja, ich weiß ich träume.
>
>www.compilers.net/Research.html
Interessant.
>In diversen Readmes von Software steht explizit drin, daß -g nicht
>ausgeschaltet werden darf.
Gibt es eigentlich überhaupt Debugger die *vernünftig* mit
hochoptimiertem Code umgehen können? Irgendwann geht doch die
Zuordnung zwischen Sourcecode(-zeilen) und Compilat ziemlich
verloren.
>>>>Mir war bekannt daß etliche Debugger ernsthafte Probleme mit dem Ergebnis
>>>>hochgezüchteter Optimizer haben aber daß der Debugger das Compilat
>>>>verändert...
>>>
>>>Entweder Du kannst den Debugger anwenden oder Du hast Codefehler.
>>
>>Eben. Meine Rede gegen hochoptimierende Compiler.
>
>Nein, gegen unzureichende Debugger.
Hmm. Das Beispiel mit for ( i = 0; i < 100; i++ ) j = 42; -> i = 100,
j = 42;. Wie soll der Debugger den Fall i = 30 "simulieren"? OK,
einfaches Beispiel aber Du siehst vermutlich worauf ich hinaus möchte.
>>>Optimierer dürfen nicht durch diese Tests fallen. Das ist ein Grund für
>>>Regreßforderungen.
>>
>>Schon klar. Wobei ich immer das Zittern bekomme ist wenn irgendein
>>sogenannter Projektleiter 5 d vor der Release meint, so und jetzt
>>schalten wir mal die Optimierungen ein. Ohne ausreichend testen zu
>>können was da passiert. Die Steigerung ist dann ein "Aber es geht doch
>>alles", wenn man mal schnell 0.1% der Funktionalität "getestet" hat.
>
>Deswegen habe ich volle Optimierungseinstellung von Beginn an laufen.
Ich habe mental die Zeit in der Compilerläufer länger als 5 Minuten
dauerten nochnicht überwunden ;)
>Die globale Datenflußanalyse bringt einfach mehr Fehler zum Vorschein.
Gut, so kann man es auch machen.
>>Ebenfalls klar. Wobei es schon einen Unterschied macht, auf welcher
>>Ebene die Optimierung ansetzt. Manche Compiler sind so anständig,
>>manche Optimierungen als potentiell unsicher zu charakterisieren.
>
>Warum implementieren sie diese dann so fehlerhaft?
Mich mußt Du das nicht fragen. Es ist allerdings zumindest
anständiger als garnix zu sagen.
~dietz
Florian Weimer
> gdb ist unbedienbar, zeigt falsche Ergebnisse und findet keine
> Compilerfehler.
Fehler bei der Bestimmung der Stack-Frame-Addresse bei eingeschaltetem
"-fomit-frame-pointer" kann man wohl nur durch statische Analyse
finden (geht zumindest mir so). Abgesehen davon hat GDB in meiner
Toolchain mit Abstand die meisten Bugs.
> Compilerfehler sind die, die Hans beschrieben hat. Mit -g werden zusätzliche
> Inspection Points eingefügt,
AFAIK nicht bei GCC.
Florian Weimer
> Lutz Donnerhacke <lu...@iks-jena.de> wrote:
> > >Ich _erwarte_ von meinem Compiler sogar, daß er die Semantik ändert:
> > >
> > > int i,j;
> > > for (i=0; i<100; i++)
> > > j=5;
> > >
> > >sollte der Compiler z.B. nach
> > >
> > > int i=100,j=5;
> > >
> > >transformieren.
> > Das ist semantisch äquivalent.
>
> Nicht, wenn du eine Interrupt-Routine hast, die annimmt, daß i auch mal
> bei 80 vorbeikommt.
Ich weiß nicht, von welcher Sprache Du schreibst. In C sind die
beiden Konstrukte äquivalent, da sie dieselbe Folge von Nebeneffekten
erzeugen (nämlich keine).
[GDB-disassemble]
> Ich habe damit auch durchaus längere Funktionen untersucht.
GCC-Output ist deutlich leichter lesbar.
Bodo Moeller
>> [...] Dazu gibt es einen ganzen Abschnitt im Drachenbuch Kapitel 10 und
>> im Ada95 Reference Manual.
> Beide befinden sich nicht in meinem Besitz.
man Internet: <URL: http://www.adahome.com/Resources/refs/rm95.html>.
Welchen Abschnitt Lutz meint, wird er selbst zeigen müssen.
Bodo Moeller
> (gdb) list
> gibt dir Kontext.
Oder gdb im Emacs.
> (gdb) p (i*3)
> Cut-und-paste des Ausdrucks in deinem Code mußt du halt mit screen oder
> deiner Maus machen.
Oder mit Emacs.
> Der Debugger ist kein Fehlersucher, sondern ein Werkzeug, mit dem _du_
> Fehler suchen kannst.
Dass man einem Programm beim Arbeiten zusehen will, heißt noch lange
nicht, dass es Fehler hat -- ein Architekt sieht sich nicht nur seine
Bauzeichnungen an, sondern auch die Baustelle; und das nicht erst,
wenn das Haus eingestürzt ist. Bei derartigen Programmbeobachtungen
ist mir das stückweise "list" zu umständlich, der Emacs-Modus gibt
einen besseren Überblick darüber, was passiert (und Breakpoints lassen
sich schneller setzen).
Hans Bonfigt
> * Dietz Proepper:
> >Schon klar. Wobei ich immer das Zittern bekomme ist wenn irgendein
> >sogenannter Projektleiter 5 d vor der Release meint, so und jetzt
> >schalten wir mal die Optimierungen ein. Ohne ausreichend testen zu
> >können was da passiert. Die Steigerung ist dann ein "Aber es geht
> >doch alles", wenn man mal schnell 0.1% der Funktionalität "getestet"
> >hat.
>
Erstaunlich. Vollste Uebereinstimmung. Dennoch lasse ich eigentlich
immer vorher einen 'lint' darueberlaufen. Auf diese Art und Weise
_spart_ Option -O3 insgesamt Zeit, obwohl der Compiler gut die drei-
fache Ausfuehrungszeit benoetigt.
Desweiteren habe ich selten Faelle, in denen '-O3' nicht funktioniert,
dagegen jedoch keinen erlebt, bei dem ein '-O3' erfolgreich war und
unoptimierte Uebersetzung nicht.
Holger Veit
Hans Bonfigt <bonfigt....@t-online.de> wrote:
[...]
>Das Problem ist hier, dass der Compiler die speziellen Implikationen
>von setjmp() nicht kennt. Er geht davon aus, dass alle lokalen Va-
>riablen, von eventuellen Argumenten abgesehen, nicht referenziert
>werden koennen. Faktisch aber wird in Falle von 'setjmp()' _jede_
>lokale Variable referenziert.
>Weil dem Compiler dieses Wissen fehlt, entscheidet er sich aus zwei
>guten Gruenden, die Wertzuweisung zu verschieben. Das Schwein macht
>reproduzierbar aus
>
> status_var=<val>;
> reason=setjmp(stack_context);
> if (reason>0) do_err_handling_and_exit(reason,status_var);
>
> reason=setjmp(stack_context);
> if (reason>0) {
> status_var=<val>;
> do_err_handling_and_exit(reason,status_var);
> }
>
>respektive, wenn status_var nachfolgend nochmals referenziert wird:
>
> reason=setjmp(stack_context);
> status_var=<val>;
> if (reason>0) do_err_handling_and_exit(reason,status_var);
>
>Wenn ich nun die Frechheit besitze, 'status_var' im Hauptprogramm
>zu modifizieren, z.B.
>
> status_var=EVENT_ARRIVED;
> rc=process_event(...);
Was tut er, wenn man status_var bzw. die Variablen der RHS <val> volatile
macht?
Holger
--
begin LOVE-LETTER-FOR-YOU.txt.vbs
You are using dangerous junk software which will arbitrarily interpret
fully valid text. Get rid of this garbage and use correctly working software.
end
Lutz Donnerhacke
>>>AttachToProcess. Oh. Geht das unter Linux überhaupt?
>>
>>Ja, aber das will man nicht.
>
>Warum nicht? Aus meiner Sicht ergänzen sich gut gemachtes Logging und
>eine Debugger glänzend. Das Logging erlaubt mir, viele Fälle einfach
>zu analysieren und im Rest der Fälle gibt es gute Hinweise, wo der
>erste breakpoint zu setzen ist.
Ich mag nicht im Maschinencode eines Prozesses rumlesen, der beim Zuschalten
eines Debuggers die Race Condition nicht mehr nachvollziehen kann.
Lutz Donnerhacke
>Gibt es eigentlich überhaupt Debugger die *vernünftig* mit
>hochoptimiertem Code umgehen können? Irgendwann geht doch die
>Zuordnung zwischen Sourcecode(-zeilen) und Compilat ziemlich
>verloren.
Nicht danach gesucht.
>Lutz Donnerhacke wrote:
>>Nein, gegen unzureichende Debugger.
>
>Hmm. Das Beispiel mit for ( i = 0; i < 100; i++ ) j = 42; -> i = 100,
>j = 42;. Wie soll der Debugger den Fall i = 30 "simulieren"? OK,
>einfaches Beispiel aber Du siehst vermutlich worauf ich hinaus möchte.
Bei der Definition der Variablen wird die Zuweisung im Debugger sichtbar.
Die Schleife ist nicht im Debugger greifbar.
>>Deswegen habe ich volle Optimierungseinstellung von Beginn an laufen.
>
>Ich habe mental die Zeit in der Compilerläufer länger als 5 Minuten
>dauerten nochnicht überwunden ;)
Seperate Compilierung geht prima. man gnatmake.
>>>Ebenfalls klar. Wobei es schon einen Unterschied macht, auf welcher
>>>Ebene die Optimierung ansetzt. Manche Compiler sind so anständig,
>>>manche Optimierungen als potentiell unsicher zu charakterisieren.
>>
>>Warum implementieren sie diese dann so fehlerhaft?
>
>Mich mußt Du das nicht fragen. Es ist allerdings zumindest
>anständiger als garnix zu sagen.
Ein irgendwo in 200k Text versteckter Hinweis auf eine Fußnote, die ein
Problem in einer obskuren Situation (nach Meinung der Compilerbauer)
beschreibt ist IMHO nicht akzeptabel.
Lutz Donnerhacke
>Das Problem ist hier, dass der Compiler die speziellen Implikationen
>von setjmp() nicht kennt. Er geht davon aus, dass alle lokalen Va-
>riablen, von eventuellen Argumenten abgesehen, nicht referenziert
>werden koennen. Faktisch aber wird in Falle von 'setjmp()' _jede_
>lokale Variable referenziert.
volatile.
Lutz Donnerhacke
>lu...@iks-jena.de (Lutz Donnerhacke) writes:
>> gdb ist unbedienbar, zeigt falsche Ergebnisse und findet keine
>> Compilerfehler.
>
>Fehler bei der Bestimmung der Stack-Frame-Addresse bei eingeschaltetem
>"-fomit-frame-pointer" kann man wohl nur durch statische Analyse
>finden (geht zumindest mir so). Abgesehen davon hat GDB in meiner
>Toolchain mit Abstand die meisten Bugs.
Danke. Ich verfolge dessen Entwicklung nicht mehr.
>> Compilerfehler sind die, die Hans beschrieben hat. Mit -g werden zusätzliche
>> Inspection Points eingefügt,
>
>AFAIK nicht bei GCC.
Mag sein. Ich kann mich irren.
Lutz Donnerhacke
>> Im aktuellen Scope sichtbare.
>
>Um Gottes Willen, das können Millionen sein, wenn du irgendwelche
>obskuren 3rd-Party-Libraries dazulinkst.
Nunja.
>Beschränke dich lieber auf die lokalen Variablen:
>
>(gdb) info locals
>
>Und wenn du unbedingt die statischen und globalen Variablen haben
>willst, hilft
>
>(gdb) info variables
Danke.
>> Du weißt, was passiert, wenn man mehr als eine Funktion debuggen will?
>
>Da der Prozessor gewöhnlich genau eine Funktion zur Zeit abarbeitet,
>debuggt man gewöhnlich auch nur eine Funktion zur Zeit.
Du hast sehr einfach gestrickte Programme. Glückspilz.
>> >Cut-und-paste des Ausdrucks in deinem Code mußt du halt mit screen oder
>> >deiner Maus machen.
>> Ich habe schon Systeme gesehen, bei denen ich den Ausdruck im Quelltext nur
>> markieren mußte oder den Mauszeiger drauf liegen lassen mußte, um das zu
>> erhalten. Warum der Umstand?
>
>Mauszeiger liegen lassen ist langsamer als cut-und-paste.
Die Semantik des Wortes 'oder' ist Dir bekannt?
>> >Das ist Problem des Compilers, nicht des Debuggers.
>> >Wenn dein Debugger bei -g anderen Code erzeugt, dann ist er kaputt.
>> Mein Compiler erzeugt bei -g anderen Code. Es ist ein gcc.
>
>Ja und?
>Das auf den Debugger zu schieben ist Verdrehung der Tatsachen.
Ein Debugger, der Modifikationen erzwingt, um überhaupt nutzbar zu sein, ist
also nicht schuld?
Holger Marzen
>
>Ich mag nicht im Maschinencode eines Prozesses rumlesen, der beim Zuschalten
>eines Debuggers die Race Condition nicht mehr nachvollziehen kann.
Jeder Debuggingprozess wird das Timigverhalten verändern. Zeitprobleme
oder (damit gekoppelte) Raceconditions wirst du damit nicht debuggen
können. Da hilft wohl nur Minimierung des Impacts indem man (die
hoffentlich später hilfreichen Informationen) in eine RAM-Tabelle
schreibt. Aber das ist eine Verzweiflungstat, kein ordentliches
Debugging.
Kann man z.B. Interruptroutinen überhaupt vernünftig debuggen?
Dietz Proepper
>* Dietz Proepper wrote:
>>>>AttachToProcess. Oh. Geht das unter Linux überhaupt?
>>>
>>>Ja, aber das will man nicht.
>>
>>Warum nicht? Aus meiner Sicht ergänzen sich gut gemachtes Logging und
>>eine Debugger glänzend. Das Logging erlaubt mir, viele Fälle einfach
>>zu analysieren und im Rest der Fälle gibt es gute Hinweise, wo der
>>erste breakpoint zu setzen ist.
>
>eines Debuggers die Race Condition nicht mehr nachvollziehen kann.
Gut, in soeinem Fall sind wir aber ohnehin far beyond and above eines
jeden Debuggers. Sogar Dein Logging wird Dir hier den Effekt verhauen.
~dietz
Dietz Proepper
>* Dietz Proepper wrote:
>>Lutz Donnerhacke wrote:
>>
>>Hmm. Das Beispiel mit for ( i = 0; i < 100; i++ ) j = 42; -> i = 100,
>>j = 42;. Wie soll der Debugger den Fall i = 30 "simulieren"? OK,
>>einfaches Beispiel aber Du siehst vermutlich worauf ich hinaus möchte.
>
>Bei der Definition der Variablen wird die Zuweisung im Debugger sichtbar.
>Die Schleife ist nicht im Debugger greifbar.
In dem einfachen Fall ist das natürlich einfach. Wenn der Compiler
aber anfängt, in einem etwas größeren Sichtbereich Invarianten zu
eliminieren oder gar aggressiv Code umstellt?
>>>Deswegen habe ich volle Optimierungseinstellung von Beginn an laufen.
>>
>>Ich habe mental die Zeit in der Compilerläufer länger als 5 Minuten
>>dauerten nochnicht überwunden ;)
>
>Seperate Compilierung geht prima. man gnatmake.
Mein ordinäres Make kann das imho genauso ;) Nee, gibt halt leider
Situationen wo ich es mir nicht erlauben kann, auf einen Debugger zu
verzichten (viel Spaß bei Loggen im Kontext von GUI-Programmierung)
und dieser gleichzeitig nicht mächtig genug ist, optimierten Code
darzustellen.
Man glaube es mir oder man glaube es nicht - einen etwas älteren
MS-Compiler (MS C 5.0, so '90 rum) habe ich echt dabei erwischt wie
der Optimizer einen Heisenbug nach dem anderen optimiert hat. Nun gut,
sogar die Microsofties haben damals zugegeben daß die aggressiven
Optimierungen im Labor besser als im rl funktionierten.
>>>>Ebenfalls klar. Wobei es schon einen Unterschied macht, auf welcher
>>>>Ebene die Optimierung ansetzt. Manche Compiler sind so anständig,
>>>>manche Optimierungen als potentiell unsicher zu charakterisieren.
>>>
>>>Warum implementieren sie diese dann so fehlerhaft?
>>
>>Mich mußt Du das nicht fragen. Es ist allerdings zumindest
>>anständiger als garnix zu sagen.
>
>Ein irgendwo in 200k Text versteckter Hinweis auf eine Fußnote, die ein
>Problem in einer obskuren Situation (nach Meinung der Compilerbauer)
>beschreibt ist IMHO nicht akzeptabel.
*g* ich meinte auch daß der Compiler von sich aus sagt "I might break
somethin' soon".
~dietz
--
Hans Bonfigt
>
> Was tut er, wenn man status_var bzw. die Variablen der RHS <val>
> volatile macht?
Danke fuer den Tip - es funktioniert. Trotzdem ist diese Vorgehens-
weise noch keine Loesung fuer mich, da
--> es mir widerstrebt, lokale Variablen (nicht Zeiger) als
'volatile' zu deklarieren, was sie per definitionem nicht sind.
--> ich wieder eine haessliche Tretmine hinterlasse fuer denjenigen,
der mein Programm spaeter erweitern will. Der deklariert eine
lokale Variable, weist sie vor 'setjmp()' zu und wundert sich.
--> ich nicht weiss, ob diese Loesung _portabel_ ist.
Denn "eigentlich" instruiert 'volatile' den Compiler ja nur,
alle Zugriffe auf die so deklarierte Variable direkt ueber
den Hauptspeicher zu realisieren, weil, z.B., deren Inhalt
von anderen Prozessen jederzeit veraendert worden sein kann.
Im Falle IBM hindert die 'volatile' - Deklaration den Opti-
mierer an der Verschiebung einer Wertzuweisung, in der Doku-
mentation steht davon jedoch nichts.
Ein anderer Compilerhersteller mag jedoch 'Code Motion' trotz
'volatile' - Deklaration zulassen und verstoesst nach meiner
Kenntnis nicht gegen deren Sinn.
--> ich mir grunsaetzlich mein Optimierungsergebniss kaputtmache,
wenn ich alle lokalen Variablen 'volatile' deklariere. Ich
will ja gerade, dass der Compiler Gebrauch von den 64 Univer-
salregistern des Prozessors macht und nicht, wie bei der nach
heutigen Gesichtspunkten hirnverbrannten PC-INTEL - Architek-
tur, ewig in den lahmen Cache schreibt oder gar TLB misses
erzeugt.
Es gibt bei IBM eine Direktive
#pragma isolated_call ,
die dem Compiler mittelt, dass die unmittelbar im Anschluss aufge-
rufene Funktion garantiert keine Variablen im scope modifiziert.
Damit ist der Compiler von der 'worst case assumption' entbunden,
dass _jede_ nichtlokale Variable nach dem betreffenden Call ver-
aendert worden sein kann und daher aus dem Speicher nachgeladen
werden muss.
Ich habe 'mal damit experimentiert und signifikante Performance-
verbesserungen erzielen koennen, gleichwohl ich aus Gruenden der
Sicherheit in Produktivumgebungen nie davon Gebrauch gemacht habe.
Ich haette jetzt gerne genau das Gegenteil, naemlich
#pragma is_likely_to_mess_up_everyting ,
aber diese Direktive gibt es nicht, und sie waere ausserdem nicht
portabel.
Ich lese heute noch einmal konzentriert den 'Stevens' zum Thema
'setjmp()' / 'longjmp()' und entscheide dann, was ich tun werde.
Nochmal Dank fuer den Hinweis mit 'volatile'.
Hans Bonfigt
>
> Kann man z.B. Interruptroutinen überhaupt vernünftig debuggen?
Ja. Bereits in der Designphase muss allerdings 'Diagnosefaehigkeit'
im Lastenheft stehen. Eigentlich sollte man ueberhaupt kein Projekt
beginnen, wenn man nicht weiss, wie man es hinterher testen soll.
Speziell nicht mit solchen Sachen wie dem Eiffelturm. Der erste
Teststurm kann fatale Folgen haben.
Hans Bonfigt
> Du hast sehr einfach gestrickte Programme. Glückspilz.
Du doch wohl hoffentlich auch ?
Hans Bonfigt
>
> * Hans Bonfigt wrote:
> >Das Problem ist hier, dass der Compiler die speziellen Implikationen
> volatile.
Siehe news:<392E5F...@t-online.de>
Felix von Leitner
> Ich mag nicht im Maschinencode eines Prozesses rumlesen, der beim Zuschalten
> eines Debuggers die Race Condition nicht mehr nachvollziehen kann.
Äh, Lutz, Race Conditions zeichnen sich dadurch aus, daß man sie nicht
nachvollziehen kann. Ob du da jetzt einen Debugger dazuschaltest oder
nicht.
Felix
--
But Unicode for NT is such fun! For example, the checked DbgPrint()
bluescreens above DISPATCH_LEVEL if you try to print a Unicode
string--the Unicode->ASCII translation tables are marked as pageable.
Felix von Leitner
> >Ja und?
> >Das auf den Debugger zu schieben ist Verdrehung der Tatsachen.
> Ein Debugger, der Modifikationen erzwingt, um überhaupt nutzbar zu sein, ist
> also nicht schuld?
Nein.
Du kannst ja immer mit -g kompilieren und dann am Ende strippen, wenn du
die Symbols nicht mehr haben willst.
Felix
--
The probability of someone watching you is proportional to the
stupidity of your action.
Felix von Leitner
> Desweiteren habe ich selten Faelle, in denen '-O3' nicht funktioniert,
> dagegen jedoch keinen erlebt, bei dem ein '-O3' erfolgreich war und
> unoptimierte Uebersetzung nicht.
Sowas habe ich mal bei einem Sun CC für SPARC erlebt, der ohne
Optimierung core dumpte und mit -O2 durchlief.
Ich habe mich dann erkundigt. Der Sun CC war ursprünglich ein
FORTRAN-Compiler für 68k-CPUs, den haben sie dann so lange aufgehackt,
bis er C und C++ nach SPARC übersetzt hat.
Mhh, keine weiteren Fragen.
Felix
--
Real Programmers don't need comments: the code is obvious.
Thomas Steffen
> Ich habe mich dann erkundigt. Der Sun CC war ursprünglich ein
> FORTRAN-Compiler für 68k-CPUs, den haben sie dann so lange
> aufgehackt, bis er C und C++ nach SPARC übersetzt hat.
Aha, deshalb liefert der so schnellen Code :-)
> Mhh, keine weiteren Fragen.
Mhh, keine weiteren Vorteile.
Thomas
Dietz Proepper
>Holger Veit:
>>
>> Was tut er, wenn man status_var bzw. die Variablen der RHS <val>
>> volatile macht?
>
>Danke fuer den Tip - es funktioniert. Trotzdem ist diese Vorgehens-
>weise noch keine Loesung fuer mich, da
>
>--> es mir widerstrebt, lokale Variablen (nicht Zeiger) als
> 'volatile' zu deklarieren, was sie per definitionem nicht sind.
In dem Fall eben schon. Du machst Dinge die der Compiler schwer
voraussehen kann.
>--> ich wieder eine haessliche Tretmine hinterlasse fuer denjenigen,
> der mein Programm spaeter erweitern will. Der deklariert eine
> lokale Variable, weist sie vor 'setjmp()' zu und wundert sich.
rtfm. Bzw. guter Platz für einen Kommentar zu dem Thema.
>--> ich nicht weiss, ob diese Loesung _portabel_ ist.
Ist das setjmp überhaupt?
> Denn "eigentlich" instruiert 'volatile' den Compiler ja nur,
> alle Zugriffe auf die so deklarierte Variable direkt ueber
> den Hauptspeicher zu realisieren, weil, z.B., deren Inhalt
> von anderen Prozessen jederzeit veraendert worden sein kann.
> Im Falle IBM hindert die 'volatile' - Deklaration den Opti-
> mierer an der Verschiebung einer Wertzuweisung, in der Doku-
> mentation steht davon jedoch nichts.
Das ist Teil der Semantik. Aus dem Gedächtnis:
int value = port[i]; // skip first value
value = port [i]; // real data
erlaubt dem Compiler die Annahme daß die Optimierung
int value = port[i]; // skip first value
// value = port [i]; // real data
zulässig sei.
Ein
volatile int value...
garantiert daß die Sequenz wie von Dir angegeben durchlaufen wird.
> Ein anderer Compilerhersteller mag jedoch 'Code Motion' trotz
> 'volatile' - Deklaration zulassen und verstoesst nach meiner
> Kenntnis nicht gegen deren Sinn.
Nein, ist anders spezifiziert, <dig> <dig>, Ellis, Stroustrup, The
Annotated C++ Reference Manual, 1995, p 110 (dort steht auch obiges
Beispiel).
>--> ich mir grunsaetzlich mein Optimierungsergebniss kaputtmache,
> wenn ich alle lokalen Variablen 'volatile' deklariere. Ich
Das mußt Du nicht tun.
> will ja gerade, dass der Compiler Gebrauch von den 64 Univer-
> salregistern des Prozessors macht und nicht, wie bei der nach
> heutigen Gesichtspunkten hirnverbrannten PC-INTEL - Architek-
> tur, ewig in den lahmen Cache schreibt oder gar TLB misses
> erzeugt.
Das wird Dir iirc von setjmp ohnehin meist zerbrochen.
~dietz
Lutz Donnerhacke
>On 26 May 2000 07:15:51 GMT, Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>>Ich mag nicht im Maschinencode eines Prozesses rumlesen, der beim Zuschalten
>>eines Debuggers die Race Condition nicht mehr nachvollziehen kann.
>
Nein. Der Debugger von vxWorks tut das nicht. Jeder DSP Hersteller liefert
Debugger, die nicht so defekt sind.
>oder (damit gekoppelte) Raceconditions wirst du damit nicht debuggen können.
Nicht brauchbar.
>Da hilft wohl nur Minimierung des Impacts indem man (die hoffentlich später
>hilfreichen Informationen) in eine RAM-Tabelle schreibt. Aber das ist eine
>Verzweiflungstat, kein ordentliches Debugging.
Nein, Routinen müssen so geschrieben sein, daß Race Conditions nicht
auftreten können.
>Kann man z.B. Interruptroutinen überhaupt vernünftig debuggen?
Ja. Man kann sie sogar vernünftig programmieren.
Felix von Leitner
> --> es mir widerstrebt, lokale Variablen (nicht Zeiger) als
> 'volatile' zu deklarieren, was sie per definitionem nicht sind.
Du kannst auch einfach bei IBM anrufen und ihnen sagen, daß ihr Compiler
kaputt ist.
> --> ich nicht weiss, ob diese Loesung _portabel_ ist.
> Denn "eigentlich" instruiert 'volatile' den Compiler ja nur,
> alle Zugriffe auf die so deklarierte Variable direkt ueber
> den Hauptspeicher zu realisieren, weil, z.B., deren Inhalt
> von anderen Prozessen jederzeit veraendert worden sein kann.
Nicht von anderen Prozessen, sondern von Signal-Handlern oder anderen
asynchronen Callbacks.
Zwischen Prozessen mußt du schon shared memory nehmen, und das will ich
sehen, wie du da lokale Variablen drauf deklarierst (d.h. wie du deinen
Stack mit einem anderen Prozess sharen kannst).
> Im Falle IBM hindert die 'volatile' - Deklaration den Opti-
> mierer an der Verschiebung einer Wertzuweisung, in der Doku-
> mentation steht davon jedoch nichts.
Doch, natürlich.
volatile hat genau die Funktion, dem Compiler Verschiebungen oder
Wegoptimierungen von Zuweisungen zu verbieten.
> --> ich mir grunsaetzlich mein Optimierungsergebniss kaputtmache,
> wenn ich alle lokalen Variablen 'volatile' deklariere.
Daher ist auch die eigentliche Vorgehensweise, bei IBM einen Bugreport
einzureichen.
> Ich lese heute noch einmal konzentriert den 'Stevens' zum Thema
> 'setjmp()' / 'longjmp()' und entscheide dann, was ich tun werde.
setjmp und longjmp sind stilistisch eh als böse zu bezeichnen und daher
nur selten und wenn dann gewöhnlich für die Emulation von Exception
Handling anzutreffen. Ausnahme: pth, das Multithreading über setjmp und
longjmp implementieren. In deinen Programmen werden sie also hoffentlich
eher selten auftreten, aber wie gesagt, IBM ist schuld. Die Suche nach
Workarounds gleicht dem Microsoft-Jünger, der nichts auf Outlook kommen
läßt.
Felix
Lutz Donnerhacke
>Lutz Donnerhacke wrote:
>>Bei der Definition der Variablen wird die Zuweisung im Debugger sichtbar.
>>Die Schleife ist nicht im Debugger greifbar.
>
>In dem einfachen Fall ist das natürlich einfach. Wenn der Compiler
>aber anfängt, in einem etwas größeren Sichtbereich Invarianten zu
>eliminieren oder gar aggressiv Code umstellt?
Auch dann sind bestimmte Codesegmente nicht mehr erreichbar. Bestimmte
Variablen erscheinen als (undef). Anweisungen werden durcheinander
angesprungen. Kein Problem.
>>>>Deswegen habe ich volle Optimierungseinstellung von Beginn an laufen.
>>>
>>>Ich habe mental die Zeit in der Compilerläufer länger als 5 Minuten
>>>dauerten nochnicht überwunden ;)
>>
>>Seperate Compilierung geht prima. man gnatmake.
>
>Mein ordinäres Make kann das imho genauso ;)
Nur, wenn Du ihm sagst, was er tun soll.
gnatmake braucht kein Makefile, er versteht den Sourcecode.
>Nee, gibt halt leider Situationen wo ich es mir nicht erlauben kann, auf
>einen Debugger zu verzichten (viel Spaß bei Loggen im Kontext von
>GUI-Programmierung) und dieser gleichzeitig nicht mächtig genug ist,
>optimierten Code darzustellen.
Wo ist das Problem mit GUIs? Wenn der Compiler NICHT optimiert, ist mit
einem Debugger Dank der tausenden Trivialfunktionen der Klassen nichts mehr
zu sehen. Ich habe schon mal mehrere Stunden beim Debuggen von STL Code
verbracht.
>Man glaube es mir oder man glaube es nicht - einen etwas älteren
>MS-Compiler (MS C 5.0, so '90 rum) habe ich echt dabei erwischt wie
>der Optimizer einen Heisenbug nach dem anderen optimiert hat. Nun gut,
>sogar die Microsofties haben damals zugegeben daß die aggressiven
>Optimierungen im Labor besser als im rl funktionierten.
Ein klassischer defekter Compiler.
Lutz Donnerhacke
>>--> ich wieder eine haessliche Tretmine hinterlasse fuer denjenigen,
>> der mein Programm spaeter erweitern will. Der deklariert eine
>> lokale Variable, weist sie vor 'setjmp()' zu und wundert sich.
>
>rtfm. Bzw. guter Platz für einen Kommentar zu dem Thema.
Der Compiler muß es wissen. Die CLib gehört an diesen Stellen zur Sprache.
>>--> ich nicht weiss, ob diese Loesung _portabel_ ist.
>
>Ist das setjmp überhaupt?
Ja.
>> Denn "eigentlich" instruiert 'volatile' den Compiler ja nur,
>> alle Zugriffe auf die so deklarierte Variable direkt ueber
>> den Hauptspeicher zu realisieren, weil, z.B., deren Inhalt
>> von anderen Prozessen jederzeit veraendert worden sein kann.
Korrekt.
>> Im Falle IBM hindert die 'volatile' - Deklaration den Opti-
>> mierer an der Verschiebung einer Wertzuweisung, in der Doku-
>> mentation steht davon jedoch nichts.
Korrekt. Das muß auch nicht unterbunden werden. Es ist jedoch 'da extere
Veränderung möglich' sinnvoll nicht über Punkte zu schieben, die externe
Veränderungen triggern könnten. Dazu muß der Compiler wissen, daß setjmp
dazu gehören kann oder nicht. Somit hätte er gleich den Mist seien lassen
können.
>Das ist Teil der Semantik. Aus dem Gedächtnis:
>
>int value = port[i]; // skip first value
>value = port [i]; // real data
>
>erlaubt dem Compiler die Annahme daß die Optimierung
>
>int value = port[i]; // skip first value
>// value = port [i]; // real data
>
>zulässig sei.
>
>Ein
>
>volatile int value...
Nein, ein 'volatile int port...' würde es garantieren.
>> Ein anderer Compilerhersteller mag jedoch 'Code Motion' trotz
>> 'volatile' - Deklaration zulassen und verstoesst nach meiner
>> Kenntnis nicht gegen deren Sinn.
>
>Nein, ist anders spezifiziert, <dig> <dig>, Ellis, Stroustrup, The
>Annotated C++ Reference Manual, 1995, p 110 (dort steht auch obiges
>Beispiel).
C eben. *seufz*
Lutz Donnerhacke
>Es gibt bei IBM eine Direktive
>#pragma isolated_call ,
>die dem Compiler mittelt, dass die unmittelbar im Anschluss aufge-
>rufene Funktion garantiert keine Variablen im scope modifiziert.
pragma Pure(...);
>Ich haette jetzt gerne genau das Gegenteil, naemlich
>#pragma is_likely_to_mess_up_everyting ,
>aber diese Direktive gibt es nicht, und sie waere ausserdem nicht
>portabel.
#ifdef IOS
# no pragma isolated_call
#endif
Lutz Donnerhacke
>> >Ja und?
>> >Das auf den Debugger zu schieben ist Verdrehung der Tatsachen.
>> Ein Debugger, der Modifikationen erzwingt, um überhaupt nutzbar zu sein, ist
>> also nicht schuld?
>
>Nein.
>Du kannst ja immer mit -g kompilieren und dann am Ende strippen, wenn du
>die Symbols nicht mehr haben willst.
-g schaltet den Compiler in den 'funktioniere richtig' Modus? Faszinierend.
Lutz Donnerhacke
>> eines Debuggers die Race Condition nicht mehr nachvollziehen kann.
>
>nachvollziehen kann. Ob du da jetzt einen Debugger dazuschaltest oder
>nicht.
Dann würden sie nie gefunden.
Lutz Donnerhacke
Nein. Es kommen durchaus Aufgaben vor, die Hirnaktivität erfordern.
Holger Veit
>>>>AttachToProcess. Oh. Geht das unter Linux überhaupt?
>>>
>>>Ja, aber das will man nicht.
>>
>>Warum nicht? Aus meiner Sicht ergänzen sich gut gemachtes Logging und
>>eine Debugger glänzend. Das Logging erlaubt mir, viele Fälle einfach
>>zu analysieren und im Rest der Fälle gibt es gute Hinweise, wo der
>>erste breakpoint zu setzen ist.
>
>eines Debuggers die Race Condition nicht mehr nachvollziehen kann.
Dann wirst Du aber mit Debug-by-printf auch nicht sonderlich gluecklich.
Interruptroutinen entlausen? Was denn, was denn, da haben Sie in
der Spezifikation nichts zu vorgesehen? Oh weh...
Holger
--
begin LOVE-LETTER-FOR-YOU.txt.vbs
You are using dangerous junk software which will arbitrarily interpret
fully valid text. Get rid of this garbage and use correctly working software.
end
Holger Veit
Hans Bonfigt <bonfigt....@t-online.de> wrote:
>Holger Marzen:
>>
>> Kann man z.B. Interruptroutinen überhaupt vernünftig debuggen?
>
>im Lastenheft stehen. Eigentlich sollte man ueberhaupt kein Projekt
>beginnen, wenn man nicht weiss, wie man es hinterher testen soll.
ACK. Du warst schneller. :-)
>Speziell nicht mit solchen Sachen wie dem Eiffelturm. Der erste
>Teststurm kann fatale Folgen haben.
If builders built houses the way programmers write programs,...
Ja, ja.
Holger Veit
>>> der mein Programm spaeter erweitern will. Der deklariert eine
>>> lokale Variable, weist sie vor 'setjmp()' zu und wundert sich.
>>
>>rtfm. Bzw. guter Platz für einen Kommentar zu dem Thema.
>
>Der Compiler muß es wissen. Die CLib gehört an diesen Stellen zur Sprache.
>
>>>--> ich nicht weiss, ob diese Loesung _portabel_ ist.
>>
>>Ist das setjmp überhaupt?
>
>Ja.
'Portabel' wuerde ich mit 'tragbar' uebersetzen. "setjmp" ist folglich
in diesem Sinne eher 'untragbar' ;-)
Lutz Donnerhacke
>On 26 May 2000 07:15:51 GMT, Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>>Ich mag nicht im Maschinencode eines Prozesses rumlesen, der beim Zuschalten
>>eines Debuggers die Race Condition nicht mehr nachvollziehen kann.
>
>Dann wirst Du aber mit Debug-by-printf auch nicht sonderlich gluecklich.
Richtig.
>Interruptroutinen entlausen? Was denn, was denn, da haben Sie in
>der Spezifikation nichts zu vorgesehen? Oh weh...
Mag sein, daß ich einfach C nicht dafür nehme.
Holger Veit
Hans Bonfigt <bonfigt....@t-online.de> wrote:
>Holger Veit:
>>
>> Was tut er, wenn man status_var bzw. die Variablen der RHS <val>
>> volatile macht?
>
>Danke fuer den Tip - es funktioniert. Trotzdem ist diese Vorgehens-
>weise noch keine Loesung fuer mich, da
>
> 'volatile' zu deklarieren, was sie per definitionem nicht sind.
Bei setjmp sind sie es aber. Was bei C sprachlich fehlt, ist eine
Spezifikation der Seiteneffekthaftigkeit eines Calls. Non-local
goto ist uebelster Pfusch. Und noch schlimmer dabei: es ist noch
nicht mal in der Sprache als Besonderheit festgelegt. Andererseits
stellt sich mir die Frage, warum nicht inzwischen Compilerbauer
mitgekriegt haben koennten, dass setjmp/longjmp den Flussgraphen
in schlimmster Weise verhuddelt. 'volatile' ist ein Patch im Sinne
von 'register'. Wer macht den hier den Job, Maschinencode zu basteln,
der Programmierer oder der Compiler?
>--> ich wieder eine haessliche Tretmine hinterlasse fuer denjenigen,
> der mein Programm spaeter erweitern will. Der deklariert eine
> lokale Variable, weist sie vor 'setjmp()' zu und wundert sich.
Ein wenig /*FINGER WEG, TRETMINE! */ im Sourcecode tut es nicht?
Keine echte Loesung, zugegeben.
>--> ich nicht weiss, ob diese Loesung _portabel_ ist.
> Denn "eigentlich" instruiert 'volatile' den Compiler ja nur,
> alle Zugriffe auf die so deklarierte Variable direkt ueber
> den Hauptspeicher zu realisieren, weil, z.B., deren Inhalt
> von anderen Prozessen jederzeit veraendert worden sein kann.
> Im Falle IBM hindert die 'volatile' - Deklaration den Opti-
> mierer an der Verschiebung einer Wertzuweisung, in der Doku-
> mentation steht davon jedoch nichts.
> Ein anderer Compilerhersteller mag jedoch 'Code Motion' trotz
> 'volatile' - Deklaration zulassen und verstoesst nach meiner
> Kenntnis nicht gegen deren Sinn.
Code motion ist erlaubt, solange man im selben Basic Block bleibt.
Die Suende liegt beim Versuch "intelligenter" Compiler, trotz
unvollstaendiger Information global zu optimieren.
>--> ich mir grunsaetzlich mein Optimierungsergebniss kaputtmache,
> wenn ich alle lokalen Variablen 'volatile' deklariere. Ich
(*) Schneller Code oder ( ) funktionierender Code? Klicken Sie
auf einen von den Radiobuttons. ;-)
>Ich lese heute noch einmal konzentriert den 'Stevens' zum Thema
>'setjmp()' / 'longjmp()' und entscheide dann, was ich tun werde.
Wenn Du mich fragst, nur wenn es wirklich nicht anders geht, drin
lassen. Sonst weg damit. Aber das ist einfacher gesagt als getan.
Hans Bonfigt
>
> pragma Pure(...);
> [ ... ]
> #ifdef IOS
> # no pragma isolated_call
> #endif
Wo hast Du denn die her ?
Mein xlc 3.1 fuer AIX 4.1.5 weigert sich, sie zu kennen.
Hans Bonfigt
> * Hans Bonfigt:
Also, mein Gehirn ist mit den Ueberlegungen zu 'setjmp()' bereits zu
80 Prozent ausgelastet.
Wenn ich kompliziertere Dinge mache, enden die meist fuerchterlich.
Da ich meine Beschraenktheit mittlerweile einzuschaetzen weiss,
versuche ich, eine mich ueberfordernde Problemstellung weiter in
elementarere Bestandteile zu zerlegen, solange, bis die Loesung des
Teilproblems einfach ist.
Wenn auch dieses Aufspalten mich ueberfordert, habe ich kein Problem,
abzulehnen.
Aber ich glaube Dir gerne, dass Dein Gehirn abstraktere und komplexere
Strukturen bewaeltigen kann als meins. Intelligenz ist, wie auch das
Abstraktionsvermoegen, normal verteilt.
Gruss,
Holger Veit
>* Hans Bonfigt wrote:
>>Es gibt bei IBM eine Direktive
>>#pragma isolated_call ,
>>die dem Compiler mittelt, dass die unmittelbar im Anschluss aufge-
>>rufene Funktion garantiert keine Variablen im scope modifiziert.
>
>pragma Pure(...);
Reales Pragma, oder Ada-Abstraktion (bei VHDL existiert sowas, daher
vermute ich, dass die das von Ada geklaut haben)?
Lutz Donnerhacke
>(*) Schneller Code oder ( ) funktionierender Code? Klicken Sie
>auf einen von den Radiobuttons. ;-)
( ) Compiler oder (*) Regreßgrund.
>>Ich lese heute noch einmal konzentriert den 'Stevens' zum Thema
>>'setjmp()' / 'longjmp()' und entscheide dann, was ich tun werde.
>
>Wenn Du mich fragst, nur wenn es wirklich nicht anders geht, drin
>lassen. Sonst weg damit. Aber das ist einfacher gesagt als getan.
Richtig. C ist ungeeignet zum Programmieren. Fehlerfälle sind ohne setjmp
nicht korrekt abfangbar.
Lutz Donnerhacke
>On 26 May 2000 13:49:45 GMT, Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>>>die dem Compiler mittelt, dass die unmittelbar im Anschluss aufge-
>>>rufene Funktion garantiert keine Variablen im scope modifiziert.
>>
>>pragma Pure(...);
>
>Reales Pragma, oder Ada-Abstraktion (bei VHDL existiert sowas, daher
>vermute ich, dass die das von Ada geklaut haben)?
Geklaut, ja. Pure ist noch weitreichender und kann sich auf ganze
Bibliotheken ausdehnen. Dann betrifft es die Elaboration dieser Bibliotheken
und deren Unterbibliotheken.
Lutz Donnerhacke
Strange. Dann arbeite ich falsch.
>Ich sehe Programmierer dann normalerweise folgende Maßnahmen ergreifen:
> a. [ruf auf] [fehler tritt nicht auf] "siehst du? geht doch!"
> b. printfs einfügen
> e. Code hin- und herschieben
> d. Wild Semaphoren und Mutexe einfügen
> e. [Kopfkratzen]
d. riecht nicht nach Logik.
> f. "Das ist bestimmt ein Hardwareschaden"
> g. "Das ist ein Compilerbug!"
> h. "Das Betriebssystem ist schuld!"
> i. Man kompiliert mit anderen Optimizer-Settings, das Timing ändert
> sich subtil, es scheint plötzlich zu tun. "War ein Optimizer-Bug"
Argl.
Felix von Leitner
> >> Ich mag nicht im Maschinencode eines Prozesses rumlesen, der beim Zuschalten
> >> eines Debuggers die Race Condition nicht mehr nachvollziehen kann.
> >nachvollziehen kann. Ob du da jetzt einen Debugger dazuschaltest oder
> >nicht.
> Dann würden sie nie gefunden.
Du wirst lachen, Lutz, das werden sie auch nicht ;-)
Ich sehe Programmierer dann normalerweise folgende Maßnahmen ergreifen:
a. [ruf auf] [fehler tritt nicht auf] "siehst du? geht doch!"
b. printfs einfügen
e. Code hin- und herschieben
d. Wild Semaphoren und Mutexe einfügen
e. [Kopfkratzen]
f. "Das ist bestimmt ein Hardwareschaden"
g. "Das ist ein Compilerbug!"
h. "Das Betriebssystem ist schuld!"
i. Man kompiliert mit anderen Optimizer-Settings, das Timing ändert
sich subtil, es scheint plötzlich zu tun. "War ein Optimizer-Bug"
Felix
--
2) Nobody wants to break into one, anyhow.
--Things that are secure about NT, cited by John D. Forinash
Holger Marzen
>>oder (damit gekoppelte) Raceconditions wirst du damit nicht debuggen können.
>
>Nicht brauchbar.
>
>>Da hilft wohl nur Minimierung des Impacts indem man (die hoffentlich später
>>hilfreichen Informationen) in eine RAM-Tabelle schreibt. Aber das ist eine
>>Verzweiflungstat, kein ordentliches Debugging.
>
>Nein, Routinen müssen so geschrieben sein, daß Race Conditions nicht
>auftreten können.
>
>>Kann man z.B. Interruptroutinen überhaupt vernünftig debuggen?
>
>Ja. Man kann sie sogar vernünftig programmieren.
Aber Lutz, wir reden doch von Debuggern. Und die braucht man nur zum
Debuggen, also wenn das Kind in den Brunnen gefallen ist. Wenn Programme
so geschrieben sind, dass keine Raceconditions auftreten und sie
"vernünftig" programmiert sind, dann tun sie was sie sollen. Kein Grund,
sich weiter mit ihnen zu beschäftigen. Ob mit oder ohne Debugger.
Hans Bonfigt
>
> Richtig. C ist ungeeignet zum Programmieren. Fehlerfälle sind ohne
> setjmp nicht korrekt abfangbar.
Sagen wir: Schwierig. Obwohl ich 'setjmp()' ausschliesslich zum
Abfangen fataler Fehler verwende, waere es ein Mordsaufwand, auch
nur ein einziges Programmsystem so umzustellen, dass es ohne aus-
kaeme.
Hans Bonfigt
> > > Kann man z.B. Interruptroutinen überhaupt vernünftig debuggen?
> > Ja. Man kann sie sogar vernünftig programmieren.
>
> Aber Lutz, wir reden doch von Debuggern. Und die braucht man nur
> zum Debuggen, also wenn das Kind in den Brunnen gefallen ist. Wenn
> Programme so geschrieben sind, dass keine Raceconditions auftreten
> und sie "vernünftig" programmiert sind, dann tun sie was sie sollen.
> Kein Grund, sich weiter mit ihnen zu beschäftigen. Ob mit oder ohne
> Debugger.
Deswegen benutzt er ja auch keinen.
Ich uebrigens auch nicht.
Hans Bonfigt
>
> Ein wenig /*FINGER WEG, TRETMINE! */ im Sourcecode tut es nicht?
> Keine echte Loesung, zugegeben.
Klappt aber. Heisst bei uns
/* BIGELO */
fuer "Billig und geschmacklos".
$ grep BIGELO $K/*.[hc]
/home/kaiser2/sources/abfunc.c: /* BIGELO */
/home/kaiser2/sources/abfunc.c: /* BIGELO */
/home/kaiser2/sources/oei.c: /* BIGELO */
$
Und es muessen nicht nur Tretminen sein. Mit Schrecken sehe ich:
/* BIGELO */
prt(STRTYPE,PR_BOLD,by,bx+h+11,
(kunum!=11301) ?"RABATT" :"FRACHTVERGšTUNG"
);
prt(DBLTYPE,PR_NORM,by++,bx+65,epr_rababs,"XXXX.XX0,XX");
...
Selber schuld, wenn man speziell fuer einen Kunden einen anderen
Text fuer "Rabatt" haben muss. Pfeffersaecke eben, so sind sie.
Aber trotzdem kommt das irgendwann einmal dort weg.
> Wenn Du mich fragst, nur wenn es wirklich nicht anders geht, drin
> lassen. Sonst weg damit. Aber das ist einfacher gesagt als getan.
Wie wahr. Obwohl sie in knapp 60.000 Zeilen ...
$ grep setjmp $K/*.[hc]
/home/kaiser2/sources/gierrhdl.c: if ((ier=setjmp(stackcontext))!=0) {
/home/kaiser2/sources/gifunc.c:#include <setjmp.h>
/home/kaiser2/sources/gixyy0.c:#include <setjmp.h>
/home/kaiser2/sources/gixyy1.c:#include <setjmp.h>
/home/kaiser2/sources/gixyy2.c:#include <setjmp.h>
/home/kaiser2/sources/gixyy3.c:#include <setjmp.h>
/home/kaiser2/sources/gixyy8.c:#include <setjmp.h>
/home/kaiser2/sources/gixyy8.c: if ((ier=setjmp(stackcontext))!=0) {
/home/kaiser2/sources/instintrhdl.c: if ((rclongjmp=setjmp(st_context))<0) {
/home/kaiser2/sources/interrupt.h:#include <setjmp.h>
... nur dreimal vorkommt, kann ich ohne aberwitzigen Aufwand nicht
darauf verzichten, Lutz hat da wie desoefteren weitgehend recht.
Lutz Donnerhacke
>Lutz Donnerhacke:
>> pragma Pure(...);
>> [ ... ]
>> #ifdef IOS
>> # no pragma isolated_call
>> #endif
>
>Wo hast Du denn die her ?
man joke.
>Mein xlc 3.1 fuer AIX 4.1.5 weigert sich, sie zu kennen.
Ist das einer von denen, die sich mit dem Rücksetzen des Datums nach
Lizenzablauf wiederbeleben lassen?