github/ghidra
1
1
Fork 0
mirror of https://github.com/NationalSecurityAgency/ghidra.git synced 2026-01-09 22:17:55 -05:00
Code Issues Packages Projects Releases Wiki Activity

GP-0: from review

Browse Source
This commit is contained in:
d-millar
2025-01-10 20:50:09 +00:00
parent 4fd092bb73
commit fe71611803
6 changed files with 119 additions and 119 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
GhidraDocs/GhidraClass/Debugger/B5-AddingDebuggers.html
View File

@@ -132,7 +132,7 @@
<h3>Unit tests</h3>
<p>The hardest part of writing unit tests is almost always getting the first test to run, and the easiest unit tests, as with the Python files, are those for <code>commands.py</code>. For <strong>drgn</strong>, as before, we’re using <strong>dbgeng</strong> as the pattern, but several elements had to be changed. Because the launchers execute a script, we need to amend the <code>runThrowError</code> logic (and, more specifically, the <code>execInPython</code> logic) in <a href="../../../Ghidra/Test/DebuggerIntegrationTest/src/test.slow/java/agent/drgn/rmi/AbstractDrgnTraceRmiTest.java"><code>AbstractDrgnTraceRmiTest</code></a> with a <code>ProcessBuilder</code> call that takes a script, rather than writing the script to stdin. While there, we can also trim out the unnecessary helper logic around items like breakpoints, watchpoints, etc. from all of the test classes.</p>
<p>JUnits for <code>methods.py</code> follow a similar pattern, but, again, getting the first one to run is often the most difficult. For <strong>drgn</strong>, we’ve had to override the timeouts in <code>waitForPass</code> and <code>waitForCondition</code>. After starting with hardcoded paths for the test target, we also had to add logic to re-write the <code>PREAMBLE</code> on-the-fly in <code>execInDrgn</code>. Obviously, with no real <code>hooks.py</code> logic, there’s no need for <code>DrgnHooksTest</code>.</p>
<p>Of note, we’ve used the gdb <code>gcore</code> command to create a core dump for the tests. Both user- and kernel-mode require privileges to run the debugger, and, for testing, that’s not ideal. <a href="../../../Ghidra/Test/DebuggerIntegrationTest/build.gradle"><code>build.gradle</code></a> will also need to be modified to include the new debugger package.</p>
<p>Of note, we’ve used the gdb <code>gcore</code> command to create a core dump for the tests. Both user- and kernel-mode require privileges to run the debugger, and, for testing, that’s not ideal. <a href="../../../Ghidra/Test/DebuggerIntegrationTest/build.gradle"><code>build.gradle</code></a> for IntegrationTest projext will also need to be modified to include the new debugger package.</p>
</section>
<section id="documentation" class="level3">
<h3>Documentation</h3>

2
GhidraDocs/GhidraClass/Debugger/B5-AddingDebuggers.md
View File

@@ -211,7 +211,7 @@ Obviously, with no real `hooks.py` logic, there's no need for `DrgnHooksTest`.
Of note, we've used the gdb `gcore` command to create a core dump for the tests.
Both user- and kernel-mode require privileges to run the debugger, and, for testing, that's not ideal.
[`build.gradle`](../../../Ghidra/Test/DebuggerIntegrationTest/build.gradle) will also need to be modified to include the new debugger package.
[`build.gradle`](../../../Ghidra/Test/DebuggerIntegrationTest/build.gradle) for IntegrationTest projext will also need to be modified to include the new debugger package.
### Documentation