Memoize gdb.Block and make them hashable

In subsequent patches, it's handy if gdb.Block is hashable, so it can
be stored in a set or a dictionary.  However, doing this in a
straightforward way is not really possible, because a block isn't
truly immutable -- it can be invalidated.  And, while this isn't a
real problem for my use case (in DAP the maps are only used during a
single stop), it seemed error-prone.

This patch instead takes the approach of using the gdb.Block's own
object identity to allow hashing.  This seems fine because the
contents don't affect the hashing.  In order for this to work, though,
the blocks have to be memoized -- two requests for the same block must
return the same object.

This also allows (actually, requires) the simplification of the
rich-compare method for blocks.

Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
This commit is contained in:
Tom Tromey
2024-05-15 12:07:36 -06:00
parent ea54f7806b
commit aac3cc8258
2 changed files with 86 additions and 67 deletions

View File

@@ -119,8 +119,12 @@ gdb_test "python print (block.is_valid())" "True" \
"Check block validity"
gdb_test "python print (block_iter.is_valid())" "True" \
"Check block_iter validity"
gdb_test_no_output "python x = hash(block)" "block is hashable"
gdb_test "python print (type (x))" "<class 'int'>" "block hash is integer"
gdb_unload
gdb_test "python print (block.is_valid())" "False" \
"Check block validity after unload"
gdb_test "python print (block_iter.is_valid())" "False" \
"Check block_iter validity after unload"
gdb_test "python print (hash (block) == x)" "True" \
"block hash did not change"