Beobachten Sie, wie sich eine Variable (Speicheradresse) im Linux-Kernel ändert, und drucken Sie den Stack-Trace, wenn er sich ändert.

Ich möchte irgendwie eine Variable (oder eher eine Speicheradresse) im Linux-Kernel "beobachten" (genauer gesagt ein Kernel-Modul / Treiber). und finden Sie heraus, was es geändert hat - drucken Sie im Grunde einen Stack-Trace aus, wenn sich die Variable geändert hat.

Zum Beispiel im Kernelmodultestjiffy-hr.c gelistet am Ende vondiese AntwortIch möchte jedes Mal eine Stapelverfolgung ausdruckenruncount variable Änderungen; hoffentlich würde der Stack-Trace dann eine Erwähnung von enthaltentestjiffy_timer_functionDies ist in der Tat die Funktion, die diese Variable ändert.

Jetzt weiß ich, dass ich es gebrauchen kannkgdb eine Verbindung zu einem Debug-Linux-Kernel herzustellen, auf dem beispielsweise eine virtuelle Maschine ausgeführt wird, und sogar so Haltepunkte (hoffentlich auch Watchpoints) zu setzen - aber das Problem ist, dass ich tatsächlich einen ALSA-Treiber debuggen möchte, insbesondere die Wiedergabedma_area Buffer (wo ich unerwartete Daten erhalte) - das ist sehr zeitempfindlich; Wenn Sie den Debug-Kernel in sich selbst ausführen, wird das Timing durcheinander gebracht (geschweige denn, wenn Sie ihn in einer virtuellen Maschine ausführen).

Ein noch größeres Problem ist hierbei die Wiedergabedma_area Zeiger existiert nur während einer Wiedergabeoperation (oder mit anderen Worten zwischen dem_start und_stop Handler) - also müsste ich das aufzeichnendma_area Adresse bei jedem_start Rückruf, und dann irgendwie "planen", während der Wiedergabe "zu beobachten".

Ich hatte gehofft, dass es eine Möglichkeit gibt, so etwas direkt im Treibercode zu tun - wie in, fügen Sie hier Code hinzu_start Rückruf, der das aufzeichnetdma_area Zeiger, und verwenden Sie es als Argument für einen Befehl, der die "Überwachung" für eine Änderung initiiert; mit dem Stack-Trace aus einer entsprechenden Callback-Funktion gedruckt. (Ich bin mir bewusst, dass dies auch das Timing beeinflussen würde, aber ich hatte gehofft, dass es "leicht" genug wäre, um den "Live" -Treiberbetrieb nicht zu sehr zu beeinflussen).

Meine Frage ist also: Gibt es eine solche Technik zum Debuggen im Linux-Kernel?

Wenn nicht: Ist es möglich, einen Hardware- (oder Software-) Interrupt einzurichten, der auf eine Änderung einer bestimmten Speicheradresse reagiert? Könnte ich dann einen solchen Interrupt-Handler einrichten, der einen Stack-Trace ausgeben könnte? (obwohl ich denke, dass sich der gesamte Kontext ändert, wenn IRQ-Handler ausgeführt werden, sodass es möglicherweise falsch wäre, einen Stack-Trace zu erhalten)?

Wenn nicht: Gibt es noch andere Techniken, die es mir ermöglichen, eine Stapelverfolgung des Prozesses zu drucken, der den an einem bestimmten Speicherort im Kernel gespeicherten Wert geändert hat (hoffentlich in einem Live-Kernel ohne Debugging)?

Antworten auf die Frage(2)

Ihre Antwort auf die Frage