diff options
author | Andrew Burgess <aburgess@redhat.com> | 2023-01-12 15:47:11 +0000 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2023-02-13 14:50:37 +0000 |
commit | d159d87072ba84358cf854f3c38d7a3e955f8301 (patch) | |
tree | 6ecc1cb219e9858496cd06e37189b3f3ba24c8e9 /gdb/value.c | |
parent | 14d0e6818a022b72c265f15f63c8ccc2fc8c302a (diff) | |
download | gdb-d159d87072ba84358cf854f3c38d7a3e955f8301.zip gdb-d159d87072ba84358cf854f3c38d7a3e955f8301.tar.gz gdb-d159d87072ba84358cf854f3c38d7a3e955f8301.tar.bz2 |
gdb/python: allow Python TUI windows to be replaced
The documentation for gdb.register_window_type says:
"... It's an error to try to replace one of the built-in windows,
but other window types can be replaced. ..."
I take this to mean that if I imported a Python script like this:
gdb.register_window_type('my_window', FactoryFunction)
Then GDB would have a new TUI window 'my_window', which could be
created by calling FactoryFunction(). If I then, in the same GDB
session imported a script which included:
gdb.register_window_type('my_window', UpdatedFactoryFunction)
Then GDB would replace the old 'my_window' factory with my new one,
GDB would now call UpdatedFactoryFunction().
This is pretty useful in practice, as it allows users to iterate on
their window implementation within a single GDB session.
However, right now, this is not how GDB operates. The second call to
register_window_type is basically ignored and the old window factory
is retained.
This is because in tui_register_window (tui/tui-layout.c) we use
std::unordered_map::emplace to insert the new factory function, and
emplace doesn't replace an existing element in an unordered_map.
In this commit, before the emplace call, I now search for an already
existing element, and delete any matching element from the map, the
emplace call will then add the new factory function.
Reviewed-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'gdb/value.c')
0 files changed, 0 insertions, 0 deletions