This shows you the differences between two versions of the page.
— |
blog:pushbx:2023:0212_pr_command_recreation_tracing_and_access_variables_recent_changes_to_ldebug [2023-02-12 17:46:57 +0100 Feb Sun] (current) ecm created |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== PR command recreation, tracing and access variables, recent changes to lDebug ====== | ||
+ | |||
+ | **2023-02-08** | ||
+ | |||
+ | ===== Recreating Enhanced Debug' | ||
+ | |||
+ | Enhanced Debug, the nonfree PC DOS Retro fork of the FreeDOS Debug family, introduced the PR command. Albeit lDebug does not offer this feature it can be recreated with the RE command buffer and a repeated, silent P command. This is how to do it: | ||
+ | |||
+ | < | ||
+ | re.append @r dco2 or= v22 | ||
+ | re.append @r v22 := 0 | ||
+ | re.append @if (value byte [cs:cip] in C3, C2, CB, CA, CF) then r v22 or= 8000 | ||
+ | p FFFFF silent 1</ | ||
+ | |||
+ | DCO2 flag 8000h aborts a running T, TP, or P command. '' | ||
+ | |||
+ | Finally, we start the P command with a high repetition count to proceed-trace the debuggee until a return instruction has run. The '' | ||
+ | |||
+ | Here is the file '' | ||
+ | |||
+ | < | ||
+ | re.append @r dco2 or= v22 | ||
+ | re.append @r v22 := 0 | ||
+ | re.append @if (value byte [cs:ip] in C3, C2, CB, CA, CF) then r v22 or= 8000 | ||
+ | re.append @if (byte [cs:ip] == 8F && byte [cs:ip + 1] clr 7 == C0) then r dco2 or= 8000 | ||
+ | ; p FFFFF silent 1</ | ||
+ | |||
+ | This has a special detection added to end the run if the next instruction is an overly-longly encoded '' | ||
+ | |||
+ | |||
+ | ===== Using access variables ===== | ||
+ | |||
+ | **2023-02-09** | ||
+ | |||
+ | Tracing in lDebug until a memory variable changes is easily done without the access variables, by simply comparing a byte, word, 3byte, or dword variable to the current value in the '' | ||
+ | |||
+ | < | ||
+ | |||
+ | This also allows to trace until an interrupt service call (or a hardware interrupt handler) changes the value. | ||
+ | |||
+ | To trace until before executing an instruction that changes memory, the access variables can be used. However, this only works if the instruction in question is actually traced. That is, if an interrupt call is proceeded past (TM=0) then its handler changing the value cannot be detected this way. This is an example: | ||
+ | |||
+ | < | ||
+ | |||
+ | The benefit is twofold: The about to be write can be detected even if the same value is written as was stored previously, and the write will end the trace before it actually runs and changes the value. (This is crucial if the change would confuse or break the debugger, like writing to the interrupt 1 or interrupt 3 handlers.) | ||
+ | |||
+ | The really powerful twist is that this works with the keyword '' | ||
+ | |||
+ | |||
+ | **2023-02-10** | ||
+ | |||
+ | Possible access variable sources: | ||
+ | |||
+ | * explicit memory operands (RO, WO, or RW -- RW shows up as two variables, one for reading and the other for writing) | ||
+ | * implicit memory operands (string instructions, | ||
+ | * stack memory operands (RO or WO) | ||
+ | |||
+ | Several memory accesses can be combined, eg: | ||
+ | |||
+ | * ' | ||
+ | * ' | ||
+ | * ' | ||
+ | * arithmetic RMW operations on memory have one explicit memory operand which is read and written | ||
+ | |||
+ | **2023-02-12** | ||
+ | |||
+ | The reads of an instruction itself, including immediate operands, never shows up in access variables. Instead, the keyword '' | ||
+ | |||
+ | ===== lDebug changes ===== | ||
+ | |||
+ | * CIP and CSP variables added to allow accessing either a 16-bit or 32-bit variable depending on the CS D-bit or SS B-bit | ||
+ | * Repeat disassembly after the NEC detection long-form pop instruction, | ||
+ | * Fix some warnings in mktables (the prior change needed a change to mktables) | ||
+ | * Fix the '' | ||
+ | * Refactor NEC detection into a subfunction, | ||
+ | |||
+ | {{tag> | ||
+ | |||
+ | |||
+ | ~~DISCUSSION~~ | ||