Page MenuHomeFreeBSD

trap_cfi(9): introduce arm implementation
Needs ReviewPublic

Authored by mchoo on Sun, Sep 13, 6:19 PM.
Tags
None
Referenced Files
F172659826: D59650.id.diff
Sun, Sep 20, 12:53 AM
Unknown Object (File)
Fri, Sep 18, 8:38 PM
Unknown Object (File)
Fri, Sep 18, 6:41 PM
Unknown Object (File)
Thu, Sep 17, 8:28 PM
Unknown Object (File)
Thu, Sep 17, 6:46 PM
Unknown Object (File)
Wed, Sep 16, 6:24 PM
Unknown Object (File)
Wed, Sep 16, 5:57 PM
Unknown Object (File)
Wed, Sep 16, 4:23 PM
Subscribers

Details

Reviewers
jhb
andrew
Group Reviewers
ARM
Summary

MFC after: 2 weeks
MFC to: stable/14, stable/15
Sponsored by: FreeBSD Foundation

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 76857
Build 73740: arc lint + arc unit

Event Timeline

mchoo requested review of this revision.Sun, Sep 13, 6:19 PM

I wanted to test this through QEMU, but it seems like armv7 minidump is broken (it cannot locate allproc, stoppcbs, etc)

mchoo retitled this revision from trap_cfi(9): add assembly interface for arm to trap_cfi(9): introduce arm implementation.

I wanted to test this through QEMU, but it seems like armv7 minidump is broken (it cannot locate allproc, stoppcbs, etc)

D59716 allowed me extract kernel dump from QEMU, and the frame unwinding works as expected. Ready for review.

Of course, I don't know anything about annotating the trap frame.
However, adding instructions to the absolutely hot path(s) in the system to fix the debugger doesn't seem like a good idea to me.

Why can't stop lying about the annotation of the stored registers and properly annotate the entire trapframe (including the SPSR), allowing the debugger to do its job?

sys/arm/arm/exception.S
364–365 ↗(On Diff #186803)

Why has this change been made? It doesn't make sense to me.