demon: gather success status of setting traps, but do not fail on failure

This commit is contained in:
Ryan Fleury
2026-05-05 12:35:20 -07:00
parent 356237418f
commit 738163dcbd
3 changed files with 15 additions and 6 deletions
+7 -2
View File
@@ -223,9 +223,14 @@ dmn_set_trap(Arena *arena, DMN_Trap *trap)
{
String8 trap_inst = dmn_get_trap_inst();
U8 *swap_bytes = push_array(arena, U8, trap_inst.size);
dmn_process_read(trap->process, r1u64(trap->vaddr, trap->vaddr + trap_inst.size), swap_bytes);
dmn_process_write(trap->process, r1u64(trap->vaddr, trap->vaddr + trap_inst.size), trap_inst.str);
B32 good_read = dmn_process_read(trap->process, r1u64(trap->vaddr, trap->vaddr + trap_inst.size), swap_bytes);
B32 good_write = 0;
if(good_read)
{
good_write = dmn_process_write(trap->process, r1u64(trap->vaddr, trap->vaddr + trap_inst.size), trap_inst.str);
}
DMN_ActiveTrap *result = push_array(arena, DMN_ActiveTrap, 1);
result->good = (good_read && good_write);
result->trap = trap;
result->swap_bytes = str8(swap_bytes, trap_inst.size);
return result;
+3 -2
View File
@@ -155,9 +155,10 @@ struct DMN_TrapChunkList
typedef struct DMN_ActiveTrap DMN_ActiveTrap;
struct DMN_ActiveTrap
{
DMN_Trap *trap;
String8 swap_bytes;
DMN_ActiveTrap *next;
B32 good;
DMN_Trap *trap;
String8 swap_bytes;
};
typedef struct DMN_RunCtrls DMN_RunCtrls;
+5 -2
View File
@@ -2865,9 +2865,12 @@ dmn_ctrl_run(Arena *arena, DMN_CtrlCtx *ctx, DMN_RunCtrls *ctrls)
DMN_LNX_Process *process = dmn_lnx_process_from_handle(active_trap->trap->process);
if(!process) { continue; }
if(!dmn_process_write(active_trap->trap->process, r1u64(active_trap->trap->vaddr, active_trap->trap->vaddr + active_trap->swap_bytes.size), active_trap->swap_bytes.str))
if(!dmn_process_write(active_trap->trap->process, r1u64(active_trap->trap->vaddr, active_trap->trap->vaddr + active_trap->swap_bytes.size), active_trap->swap_bytes.str) &&
active_trap->good)
{
Assert(0 && "failed to restore original instruction bytes");
// TODO(rjf): log an error here? - we wrote the trap successfully, but we did not remove it successfully,
// implying a change in address mapping. this is maybe not even a bug, since the address is simply now
// unmapped.
}
}
}