aboutsummaryrefslogtreecommitdiff
path: root/gdb/po
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2023-01-12 15:47:11 +0000
committerAndrew Burgess <aburgess@redhat.com>2023-02-13 14:50:37 +0000
commitd159d87072ba84358cf854f3c38d7a3e955f8301 (patch)
tree6ecc1cb219e9858496cd06e37189b3f3ba24c8e9 /gdb/po
parent14d0e6818a022b72c265f15f63c8ccc2fc8c302a (diff)
downloadgdb-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/po')
0 files changed, 0 insertions, 0 deletions