SW-Projetleiter Fragt: "Für was braucht man einen Debugger?"

Michael schrieb:
> Hat jemand Ideen für weitere Argumente?

und warum keinen vorhanden Debugger verwenden? Und warum sollte ein 
Kernel einen debugger haben? Ein debugger ist doch ein extra tool.

Hallo,

liegt daran das wir einen Kernelspace-Debugger benötigen und im 
aktuellen Linux das wir verwenden keiner integrert ist, was sich jedoch 
beheben lässt. Kernelspace-Debugging ist eben nicht Userspace-Debugging.

Michael schrieb:
> Die Argumente haben ihn nicht überzeugt.

Würden mich auch nicht überzeugen.

BTW: Wie denkst du dir eigentlich das "Debuggen von lokalen Variablen" 
in Funktionen? bzw. was willst du da eigentlich sehen? Normalerweise 
räumt der Compiler den Code beim Optimieren so großzügig um, daß du da 
erstmal garnix siehst - jedenfalls deinen Quellcode selten bis nie 
wirklich wiedererkennst.

Ansonsten guckt man sich den Stackverbrauch nicht per Debugger an, 
sondern benutzt die bei der Toolchain vorhandenen 
Profilier-Möglichkeiten. Sowas kann im Prinzip schon ein halbwegs 
intelligenter Linker liefern.

Michael schrieb:
> StepByStep Debugging um den Controlflow zu prüfen

Ah ja, den Controlflow.. Schreib nicht so geschwollen daher, sondern sag 
lieber, was du eigentlich meinst - es sei denne, daß es dir selbst nicht 
so recht klar ist. Du willst also dein selbstgeschriebenes Opus Zeile 
für Zeile mal durchgehen, weil du dir nicht sicher bist, was du da 
eigentlich geschrieben hast und der Compiler das übersetzt, was du 
geschrieben hast und nicht das, was du eigentlich gemeint bzw. 
beabsichtigt hast. Jahaha, das ist des C-Programmierers Schicksal.

W.S.

Michael schrieb:
> Hat jemand Ideen für weitere Argumente?

Ja, für deinen Chef. Bau einfach das gute alte printf ein und wenn du 
besser bist, dann programmierst du gleich ordentlich. Damit meine ich, 
du weißt was du tust und musst nicht erst ein anderes Programm benutzen 
um deine Arbeit zu verifizieren/falsifizieren. Der gute alte API-Test 
ist auch schneller als die 16h + Debug-Sessions.


---

Im Kernel nimmt man wohl eher printk statt printf ;)

Hallo,

stimmt, der Compiler reorganisiert den Code innerhalb der Funktion, ist 
normal. Ich habe schon Low-Level Debugging gemacht, ist kein Hindernis 
für mich, braucht etwas Training, dann geht's.

Man kann die maximale Stackauslastung sehen wenn man den Stack beim 
Startup mit einem Muster beschreibt, man sieht dann wie weit der maximal 
ausgelastet war, vor allem wenn man einen Crash hat und im Error-Hook 
ist. Dann kann man Rückschlüsse über den Stack machen aus welchem Modul 
der Fehler kommt. Besser zur Stackanalyse sind natürlich statische 
Methoden, absint liefert dafür gute Tools, hätte ich gern, hab ich 
vorgeschlagen, abgeleht.

Ich hab ganz bewusst nicht "Zeile für Zeile" geschrieben, denn das kommt 
beim Compilieren nicht raus, wie Du ja zu Anfang richtig bemerkt hast. 
Vom "Correctness by Construction" Ansatz bin ich voll überzeugt, ich 
schreibe nichts ohne vorher eine Design-Spezifikation geschrieben zu 
haben, vorher denken und reviewen hilft die Anzahl der Fehler massiv zu 
senken. Design-Review ist eine sehr mächtige Methode. Drauf los 
programmieren ist einfach nur dumm weil man sehr viele Fehler im Code 
hat, aber einige stehen drauf, ich nicht.

Dr. Dewar hat zu Ada etwas interessantes gesagt: "You can write 
Junk-Code in any language". C ist nicht die beste Sprache auf dem 
Planeten, aber ich kann mit C leben. Jede Sprache hat ihre eigenen 
Probleme, man muss die Probleme und Limits der Sprache kennen und 
umgehen. Daher gibt's ja auch MISRA-C das einige gefährliche 
Code-Konstrukte ausschließt.

Debugging mache ich um gezielt Fehler zu suchen die sich mit 
Instrumentierung und anderen Methoden nicht, oder nur schwierig finden 
lassen.

Güße

Michael

P.S. http://www.absint.com/

D. I. schrieb:
> Im Kernel nimmt man wohl eher printk statt printf ;)

Ups, ja, es ist schon etwas länger her mit meinem letzten Kontakt zum 
Kernel. Das Problem bei der Programmierung (Treiber) hat sich damals 
aber auch ergeben und durch das "printk" im Treiber konnte ich die API 
verifizieren.

Lokale Variabeln, Breakpoint's, StepByStep, Controlflow und 
Stack-Auslastung im KERNEL zu prüfen hört sich für mich nach anderen 
Problemen an.

Sowas fragt man seinen Chef auch nicht. Sowas macht man einfach. Im 
Rahmen der normalen Entwicklungsarbeit darf man sich ja wohl sein 
Environment so zusammenkonfigurieren wie man es gerade braucht.

Wen er fragt was man gerade macht, dann antwortet man wahrheitsgemäß, 
dass man im Kernel rumpopelt weil man einen Fehler sucht.

Ppp schrieb:
> Wen er fragt was man gerade macht, dann antwortet man wahrheitsgemäß,
> dass man im Kernel rumpopelt weil man einen Fehler sucht.

Er hat wohl auf die Frage "Dr. Dewar" zitiert ...

Alexander S. schrieb:
> Es gibt doch schon kernel debugger für Linux kdb auf Assembler Ebene.
> Ansonsten gibts noch den kgdb der für C funktioniert, dafür wir aber ein
> zweiter PC benötigt. Wenn man für ein Embedded System programmiert,
> verwendet man besten einen JTAG Debugger.

Es gibt alles, man muss nur abschätzen können ob sich der Aufwand lohnt 
oder nicht. Der Debugger ist das letzte und nicht das erste Mittel der 
Wahl. Wenn ein Programmierer einen Debugger bedient ist er entweder 
grade zu faul und hat viel Zeit für Spielerei oder es ist wirklich etwas 
im argen.

....

Zu der Tatsache, dass es den Debugger schon gibt (siehe Vorredner) nur 
noch eine weitere Idee, die ich gerne Umsetze:

Debugging per Testcase. Wenn was nicht funktioniert, mach ich da gleich 
einen automatisierten Test von, der (wo möglich) interne Zustände mit 
ihren erwarteten Werten überprüft. So erhalte ich wertvollen Testcode, 
der noch viele Jahre nützlich sein wird, und komme der Ursache sehr 
nahe, da der Testcode ja gleich Alarm schlägt, sobald das Verhalten 
nicht mehr stimmt.

Sam P. schrieb:
> Zu der Tatsache, dass es den Debugger schon gibt (siehe Vorredner) nur
> noch eine weitere Idee, die ich gerne Umsetze:
>
> Debugging per Testcase. Wenn was nicht funktioniert, mach ich da gleich
> einen automatisierten Test von, der (wo möglich) interne Zustände mit
> ihren erwarteten Werten überprüft. So erhalte ich wertvollen Testcode,
> der noch viele Jahre nützlich sein wird, und komme der Ursache sehr
> nahe, da der Testcode ja gleich Alarm schlägt, sobald das Verhalten
> nicht mehr stimmt.

API-Test viel schneller und sicherer. Interne Zustände vom Debugger, ihr 
scheint euren Code wirklich nicht zu vertrauen, ende aus.

Debugger schrieb:
> API-Test viel schneller und sicherer. Interne Zustände vom Debugger, ihr
> scheint euren Code wirklich nicht zu vertrauen, ende aus.

Wer redet denn von internen Debugger-Zuständen?

Systematischer Test-Code hat nichts mit dem Vertrauen in den eigenen 
Code zu tun. Solange du menschlich bist, wirst du Fehler machen. Wie 
dein einleitender Satz, der kein Verb. Oder das Missverständnis mit dem 
Debugger.

Darum braucht man eine Testsuite.

Ob man nun reine API-Tests macht oder Unit-Tests oder was auch immer, 
das ist zweitrangig. Siehe auch "black-box" vs. "white-box" testing. 
Wichtig ist nur der Nutzwert, und ein white-box Test kann eben auch als 
Debughilfe verwendet werden.

Debugger schrieb:
> Der Debugger ist das letzte und nicht das erste Mittel der
> Wahl. Wenn ein Programmierer einen Debugger bedient ist er entweder
> grade zu faul und hat viel Zeit für Spielerei oder es ist wirklich etwas
> im argen.
>
> ....

Solche Sprüche kommen normalerweise von Typen die zu blöd sind einen 
Debugger zu bedienen.

Ich vermeide mit solchen Typen zusammen zu arbeiten. Man bekommt scheiss 
Code, haufenweise Bugs, dumme Sprüche und darf hinter den "unfehlbaren" 
Angebern aufräumen.

Michael schrieb:
> Meine Argumente waren

Deine Argumente mögen technisch richtig sein. Wenn man aber einen BWLer 
überzeugen will, bzw. jemanden der so denkt wie ein BWLer, dann muss 
eine der beiden folgenden Fragen mit "ja" beantwortet werden:

-Wird durch den Einsatz eines Debuggers der Gewinn erhöht?
-Werden durch den Einsatz eines Debuggers die Kosten gesenkt?

Das ist die Sprache die diese Leute verstehen.

Alternativ kann es vielleicht auch konkrete Probleme im aktuellen 
Projekt geben, oder in vergangenen Projekten gegeben haben, die den 
Einsatz eines Debuggers rechtfertigen. Gibt es diese? Kannst du sie 
konkret benennen? Also nicht "das und jenes könnte passieren", sondern 
"genau dieses Problem ist aufgetreten"?

Firmen sind oft träge. Kleine vielleicht nicht so sehr aber die großen 
Konzerne sind dafür bekannt. Da braucht man schon gute Argumente wenn 
man was ändern will. Aus Firmensicht sind technische Argumente allein 
für eine Umstellung leider oft nicht ausreichend, auch wenn die 
Entwickler das gerne so hätten.

Alternativ könntest du dir auch einen Arbeitgeber suchen, der für seinen 
Einsatz von Debuggern bekannt ist ;-)

Ppp schrieb:
> Solche Sprüche kommen normalerweise von Typen die zu blöd sind einen
> Debugger zu bedienen.

Für die Bedienung bin ich eigentlich nicht zu blöd, meine ich :-).

> Ich vermeide mit solchen Typen zusammen zu arbeiten. Man bekommt scheiss
> Code, haufenweise Bugs, dumme Sprüche und darf hinter den "unfehlbaren"
> Angebern aufräumen.

Ach komm, jetzt bist du auch nicht besser als die "Unfehlbaren", eben 
ein kleiner Weltretter, mit denen ich vermeide zusammen zu arbeiten.

Hallo,

leider ist der Projektleiter kein BWL'ler, wäre es einer dann wäre es 
mangelnde Fachkenntnis aufgrund einer anderen Ausbildung und ich könnte 
die Entscheidung nachvollziehen.

Die Frage ob etwas Geld bringt lässt sich oft schwer berechnen, ist 
meist empirisch oder gefühlt, nicht faktisch belegt. Bringt eine 
Firmen-Fahne oder eine Fußmatte Geld? Nein, die Fußmatte hat mir noch 
nie im Projekt etwas genutzt, trotzdem haben wir Fußmatten. Kann ein 
Debugger helfen die Kosten zu senken und mehr Gewinn zu erwirtschaften? 
La, manche Fehler könnten sich mit dem Debugger schneller finden lassen, 
ein Debugger hat Potential den Gewinn zu erhöhen, die Fußmatte nicht.

Nicht ohne Grund kaufen Firmen Lauterbach-Debugger,... aber ich habe 
noch nie eine Berechnung gesehen die den finanziellen Nutzen errechnet. 
Man würde zwei Gruppen benötigen, eine mit Debuggern, eine ohne, die das 
selbe implementieren. Kennt jemand dazu wissenschaftliche Studien?

Grüße

Michael

Michael schrieb:
> Man würde zwei Gruppen benötigen, eine mit Debuggern, eine ohne, die das
> selbe implementieren.

Da müsstest du die Besetzung auslosen, damit das Ergebnis nicht 
verfälscht wird: es gibt eben verschiedene Programmierstile, z.B. den 
hirn-orientierten und den debugger-orientierten. Ich bevorzuge ersteren 
und überlege lange beim Codieren, um möglichst wenige Fehler zu 
produzieren, denn für jeden Fehler den ich nicht mache brauche ich weder 
Zeit noch Debugwerkzeuge.

Ich habe aber auch im Lauf der Jahre Programmierer kennengelernt, die 
völlig gegensätzlich arbeiten: übertrieben gesagt, jedes beliebige 
Programm besteht erst mal aus einem einzelnen NOP-Befehl, und dann wird 
der Debugger gestartet und gesucht, warum das Programm nicht das macht 
was es soll. Hat man alle Fehler debuggt ist das Programm fertig. 
Selbstredend verfügen solche Programmierer über eine optimale 
Debug-Ausstattung, und sie behaupten in der Regel, sie kämen so 
wesentlich schneller ans Ziel als wenn sie über Algorithmen usw. lange 
nachdenken würden. Bestätigen kann ich das nicht.

Ich benutze Debugger sofern vorhanden, z.B. in einer IDE, kann aber auch 
ohne arbeiten - schon deswegen weil es die in der Gründerzeit garnicht 
gab, man musste sich selbst was schreiben, z.B. LED an bei Eintritt in 
eine Routine und LED aus am Ende.

Gruss Reinhard