It turned out that cache is already cleared due to the following
changes:
```diff
- "cont": (pwndbg.gdblib.events.cont,),
+ "cont": (
+ pwndbg.gdblib.events.cont,
+ pwndbg.gdblib.events.mem_changed,
+ pwndbg.gdblib.events.reg_changed,
+ ),
```
So: `gdblib.write` is writing to memory -> GDB fires of MemoryChanged
event -> this is clearing the cache for "cont" cache and so the disasm
context works properly.
This finally closes https://github.com/pwndbg/pwndbg/issues/1818
This commit changes the name of linux kernel memory pages fetched via
gdb-pt-dump from "<pt>" to "[pt_<addr>]" to make it possible to use
those memory pages with other commands that take memory map names as
arguments, like the search command:
```
search <value> <mapping-name>
```
* Use /bin/sh instead of /bin/bash
* Install the required freebsd packages and remove some bashisms
* Reuse bash
* Attempt to fix the linter
* Fix the linter
* add libc 2.12+ functionality for structs.py
* for some reason struct itself got deleted so added it back again
* fixed bugs
* fixed lint newline at EOF cause why not
* fixed docstring and changed get_version functionality
* Update structs.py: lint + set GLIBC_VERSION
* Update structs.py
* Update structs.py
---------
Co-authored-by: Disconnect3d <dominik.b.czarnota@gmail.com>
* feat: Implement -A and -B in vmmap.py
* fix: Formatting
* Update vmmap.py
* fix: Support multiple line results in vmmap
* feat: Implement -A and -B in vmmap.py
* fix: Formatting
* fix: vmmap Sort pages by address
---------
Co-authored-by: Disconnect3d <dominik.b.czarnota@gmail.com>
* Added thread section to context
* moved thread status messages to global scope
* Update pwndbg/commands/context.py
Co-authored-by: Disconnect3d <dominik.b.czarnota@gmail.com>
* Fixed line format
---------
Co-authored-by: Disconnect3d <dominik.b.czarnota@gmail.com>
* get_one_instruction: clear "cont" cache on mem/reg changed
Fixes#1818.
Note that this makes a substantial change: it changes all caches that
are refreshed on `gdb.ContinueEvent` to also be cleared on memory/regs
changed.
This change is needed so that the `get_one_instruction` function which
uses this cache will get its cache cleared when user invokes a command
that changes memory or registers.
While this may sound as too big change: we are changing the whole "cont"
cache to be cleared on two additional events, this should not be an
issue. This is because:
1. We should notice it if we start clearing an important cache too often
2. The "cont" cache is currently only used by the `get_one_instruction`
at this moment.
The 2) also creates a question: when should one use "cont" vs "start"
caches? It is not so clear to me right now.
* Add test for issue #1818
* Clear caches on MemoryChanged events from gdblib.write
Regarding the last part:
Interestingly implementing tests here uncovered another bug: the gdblib.memory.write(..) or rather the gdb.selected_inferior().write_memory(...) API used there does not trigger a gdb.MemoryChanged event. As a result, we never cleared certain caches that should have been cleared when the user used that API.
I have added two tests here, one changes the instructions at $RIP to nops via gdblib.memory.write(..) and another via executing the patch $rip nop;nop;nop;nop;nop command. As a result, we test both scenarios: 1) when we depend on memory changed event being fired via GDB to clear caches; and 2) when we depend on gdblib.memory.write(..) to clear the caches.
This PR also makes a fix to the gdblib.memory.write(..) to actually clear caches that depend on (or rather: are hooked to in order to be cleared) memory changed events.
The only disadvantage of this is that we now display the glibc version
as a tuple like this:
```
pwndbg> set glibc 2.32
Set GLIBC version for heap heuristics resolution (e.g. 2.31) to (2, 32).
pwndbg> heap_config glibc
Name Value (Default) Documentation
--------------------------------------------
glibc (2, 32) ('') GLIBC version for heap heuristics resolution (e.g. 2.31)
```
But I think this is fine.
Until now we ran the lint job on CI on both Ubuntu 20.04 and Ubuntu 22.04. I am not sure why exactly we run it on both, but I think we can try running it only on Ubuntu 22.04 unless there are good reasons to keep both.