summaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
diff options
context:
space:
mode:
authorHans <hans@hanshq.net>2024-09-18 08:58:14 +0200
committerGitHub <noreply@github.com>2024-09-18 08:58:14 +0200
commit3d2925b9de0d60694a9f28edd2419f8eed34f1a1 (patch)
treebe999e35dfc1aa2cec9c93ffd7e0aa643fbd6fa2 /lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
parent9d3ab1c36e03d5ad23e209938c32973fbee18a57 (diff)
[win/asan] AllocateMemoryForTrampoline within 2 GB of the module's base address (#108822)
Since we may copy code (see CopyInstructions) to the trampoline which could reference data inside the original module, we really want the trampoline to be within 2 GB of not just the original function, but within anything that function may have rip-relative accesses to, i.e. within 2 GB of that function's whole module. This fixes interception failures like the following scenario: 1. Intercept `CreateProcess` in kernel32.dll, allocating a trampoline region right after 2. Start intercepting `memcpy` in the main executable, which is loaded at a lower address than kernel32.dll, but still within 2 GB of the trampoline region so we keep using it. 3. Try to copy instructions from `memcpy` to the trampoline. Turns out one instruction references data that is more than 2GB away from the trampoline, so it can't be relocated. 4. The process exits due to a CHECK failure (Full story at https://crbug.com/341936875#comment45 and following.)
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp')
0 files changed, 0 insertions, 0 deletions