Rethink debug lifecycle #1210

Activity

1. github-actions

   added

   lifecycle/needs-reviewThe issue has not yet been reviewed.The issue has not yet been reviewed.

   on Feb 4, 2026
2. ludfjig commented on Feb 4, 2026

   

   ludfjig

   on Feb 4, 2026

   Contributor

   More actions

   Note that #1120 might further change debugging due to resetting debug register on snapshot-restores, which could potentially discard breakpoints etc. One possible solution might be to not reset debug registers if gdb cargo feature is enabled?
3. danbugs

   added

   lifecycle/confirmedBug is verified or proposal seems reasonableBug is verified or proposal seems reasonable

   and removed

   lifecycle/needs-reviewThe issue has not yet been reviewed.The issue has not yet been reviewed.

   on Feb 25, 2026
4. danbugs

   added this to Hyperlight Milestoneson Feb 25, 2026
5. danbugs

   added this to the v0.15.0 milestone on Feb 25, 2026
6. dblnz commented on Feb 25, 2026

   

   dblnz

   on Feb 25, 2026

   Contributor

   More actions

   This is a note to think about the future of debugging a sandbox.
   Currently, we rely on the entrypoint function breakpoint to allow the user the time to add new breakpoints, but if a sandbox has been snapshotted after the initialise phase, that won't work.
7. simongdavies commented on Feb 25, 2026

   

   simongdavies

   on Feb 25, 2026

   Member

   More actions

   Additionally we may want to consider that restore/resetting a sandbox might work very differently as we move towards using Snapshots as the basis for creating Sandboxes

   👍React with 👍1Reacted by Doru Blânzeanu
8. dblnz

   added a parent issue on Mar 3, 2026

   • Snapshot-First Sandbox Lifecycle #1268
9. github-project-automation

   added this to Hyperlight Roadmapon Jun 17, 2026
10. jsturtevant

    modified the milestones: v0.15.0, Backlog on Jun 17, 2026
11. ludfjig

    added sub-issues on Oct 22, 2026

    • Serve gdb on the vCPU thread #1974
    • gdb: snapshot restore breaks breakpoints #1972
    • gdb: Ctrl-C then continue cancels the guest call #1973
    • gdb: register access corrupts rbx and x87 state #1971
12. ludfjig commented on Oct 22, 2026

    

    ludfjig

    on Oct 22, 2026

    Contributor

    More actions

    Status on current main:

    • Snapshot attach is partly solved. Since Create sandboxes directly from snapshots #1459, HyperlightVm::new sets the one-shot breakpoint at the next entry, so sandboxes from initialised snapshots stop at the first call. restore() does not set it again.
    • One session per sandbox, fixed at creation, still holds. The gdb thread accepts once. After a detach no client can attach again.
    • The concern from Reset more vcpu state on snapshot::restore #1120 holds on MSHV and WHP. reset_vcpu zeroes the debug registers, and those hypervisors keep gdb hardware breakpoints there. KVM keeps them in kvm_guest_debug, so they survive.

    Sub-issues:

    • Serve gdb on the vCPU thread #1974: serve gdb on the vCPU thread. This removes the gdb thread and its channels and gives the session a clear owner. A draft passes the existing gdb tests and a new Ctrl-C test.
    • gdb: snapshot restore breaks breakpoints #1972: snapshot restore breaks gdb breakpoints.
    • gdb: Ctrl-C then continue cancels the guest call #1973: Ctrl-C then continue cancels the guest call. Small fix, independent of the redesign.
    • gdb: register access corrupts rbx and x87 state #1971: gdb register access corrupts rbx and x87 state. Small fix, independent of the redesign.

    Remaining design question: when should a gdb client be able to attach? Options:

    • Only at the first entry, as today.
    • At the next guest call whenever no client is connected, using a non-blocking accept.
    • Behind an opt-in "break on every call" setting.