ARM Stacktrace analysieren

ThomasH Gast #2171154
Lesenswert?
• ▲
▼ 
Hallo,

gibt es eine Möglichkeit einen Stackdump von einem CortexM3 oder anderen 
ARMs offline zu analysieren, dh ich möchte bei Exceptions den Stack 
sichern und später wenn es geht mit dem gbd analysieren. Ist so etwas 
möglich und hat das schon wer gemacht?
Hintergrund ist folgender, unsere Produkte sind eben oft Unterwegs und 
dort treten natürlich treten gerade da Exceptions auf und jetzt wäre es 
ideal, wenn ich diese loggen könnte um sie später offline analysieren.

Was mir schon sehr helfen würde, wäre der CallStack der Funktionen, aber 
das manuell ohne Framepointer zu analysieren scheint mir jetzt auch 
keine gute Idee zu sein.
Die Adresse der Instruktion bekommt man ja recht gut beim M3, aber etwas 
mehr wäre recht nett.

gr
thomas
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Kai S. #2172015
Lesenswert?
• ▲
▼ 
ThomasH schrieb:
> Hallo,
>
> gibt es eine Möglichkeit einen Stackdump von einem CortexM3 oder anderen
> ARMs offline zu analysieren, dh ich möchte bei Exceptions den Stack
> sichern und später wenn es geht mit dem gbd analysieren. Ist so etwas
> möglich und hat das schon wer gemacht?

Spontan waehre meine Idee ein core-dump zu erstellen. Diesen sollte gdb 
einlesen koennen, und das Problem waere geloest.
Dokumentation zum core-dump findet sich als Teil der ELF Spec.

> Hintergrund ist folgender, unsere Produkte sind eben oft Unterwegs und
> dort treten natürlich treten gerade da Exceptions auf und jetzt wäre es
> ideal, wenn ich diese loggen könnte um sie später offline analysieren.

Eine andere Moeglichkeit ist ein Logging-System schon in das Produkt 
einzubauen, und gleich die Information zu dumpen die offline analysiert 
werden kann.

>
> Was mir schon sehr helfen würde, wäre der CallStack der Funktionen, aber
> das manuell ohne Framepointer zu analysieren scheint mir jetzt auch
> keine gute Idee zu sein.

Automatisieren geht ja immer.

> Die Adresse der Instruktion bekommt man ja recht gut beim M3, aber etwas
> mehr wäre recht nett.

Wie die Parameter ? Dafuer braucht man dann auf jeden Fall die 
Debug-Info.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
ThomasH Gast #2172498
Lesenswert?
• ▲
▼ 
Kai S. schrieb:
>
> Spontan waehre meine Idee ein core-dump zu erstellen. Diesen sollte gdb
> einlesen koennen, und das Problem waere geloest.
> Dokumentation zum core-dump findet sich als Teil der ELF Spec.
>

hab ich mir auch schon gedacht, aber das sollte ja wahrscheinlich nicht 
nur der Stack rein, sondern der ganze Adressraum, also zumindest noch 
die globalen Variablen.
Muss mal schauen wie aufwändig diese Lösung wäre.

> Eine andere Moeglichkeit ist ein Logging-System schon in das Produkt
> einzubauen, und gleich die Information zu dumpen die offline analysiert
> werden kann.
>

Hab mittlerweile diesen Ansatz gefunden, so eine Art ARM Simulator um 
jeweils die Functionepilogs zu finden und die Rücksprungadressen 
rauszufummeln. Sieht jedenfalls interessant aus, muss mal prüfen wie 
weit das funtkioniert.

http://www.mcternan.co.uk/ArmStackUnwinding/

>
> Automatisieren geht ja immer.
>

Ich stell mir das leider nur nicht so einfach vor, das zu 
automatisieren, siehe oben.

>> Die Adresse der Instruktion bekommt man ja recht gut beim M3, aber etwas
>> mehr wäre recht nett.
>
> Wie die Parameter ? Dafuer braucht man dann auf jeden Fall die
> Debug-Info.

Ich meinte die Adresse der Instruktion, die die Exception ausgelöst hat. 
Die Funtkion dazu ist natürlich mit dem Listing File auch kein Problem, 
aber wie schon erwähnt, wäre auch der Call Stack sehr interessant.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren