Hallo, heute hatte ich eine interessante Frage von einem Projektleiter als ich vorgeschlagen habe in den Linux Kernel einen Debugger zu integrieren: Ich weiß was ein Debugger ist, wir haben bisher ohne Debugger gearbeitet, erklär mir warum Du den benötigst. Meine Argumente waren: - Debugging in Funktionen (Lokale Variabeln) - Breakpoint's und StepByStep Debugging um den Controlflow zu prüfen - Stack-Auslastung zu prüfen (ist noch Speicher im Stack vorhanden) Risiko für's Projekt wurde mit 0 Abgeschätzt, Aufwand mit 1-2 Tagen. Die Argumente haben ihn nicht überzeugt. Hat jemand Ideen für weitere Argumente? Vielen Dank, Grüße Michael
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 ...
Michael schrieb: > Meine Argumente waren: > > - Debugging in Funktionen (Lokale Variabeln) > - Breakpoint's und StepByStep Debugging um den Controlflow zu prüfen > - Stack-Auslastung zu prüfen (ist noch Speicher im Stack vorhanden) Sind das für Dich Argumente? Für mich ist das ne Liste von schönen Features. Argumente werden da erst draus, wenn Du erklärst wie die Dir beim Entwickeln helfen und was sie am Ende bei Deinem Projekt für Vorteile bringen. > Risiko für's Projekt wurde mit 0 Abgeschätzt, Aufwand mit 1-2 Tagen. So, so. Du bist Dir also wirlich zu 100% sicher, daß Du mit diesem Kernel-Debugger die oben gelisteten Features in Deinem Kernelcode erreichen kannst? Meine Erfahrung mit Kernelcode ist eher, daß man da nicht so "einfach mal eben" debuggen kann. Denn der Debugger verändert das Verhalten des Kernels. Gerade wenn Du es mit falschen Locking-Strukturen, Nebenläufigkeiten oder Speicherallokierung zu tun hast, tritt der Bug mit dem Debugger plötzlich nicht mehr oder an ganz anderer Stelle als ohne Debugger auf. Ich würde im Kernel möglichst minimalinvasiv vorgehen.
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.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.