aboutsummaryrefslogtreecommitdiff
path: root/opcodes/ChangeLog
diff options
context:
space:
mode:
authorGeorge Barrett <bob@bob131.so>2021-06-07 04:49:58 +1000
committerSimon Marchi <simon.marchi@polymtl.ca>2021-08-09 23:20:41 -0400
commitc173cc8a666792a6e864b5beb1c4d6903169b5cd (patch)
treec928c8551cbf87757017b0f872b606e9906d429e /opcodes/ChangeLog
parentd2a2c939f187a595fc7ccdac0ffbbab1d39e9d5b (diff)
downloadgdb-c173cc8a666792a6e864b5beb1c4d6903169b5cd.zip
gdb-c173cc8a666792a6e864b5beb1c4d6903169b5cd.tar.gz
gdb-c173cc8a666792a6e864b5beb1c4d6903169b5cd.tar.bz2
guile: fix smob exports
Before Guile v2.1 [1], calls to `scm_make_smob_type' implicitly added the created class to the exports list of (oop goops); v2.1+ does not implicitly create bindings in any modules. This means that the GDB manual subsection documenting exported types is not quite right when GDB is linked against Guile <v2.1 (types are exported from (oop goops)) instead of (gdb)) and incorrect when linked against Guile v2.1+ (types are not bound to any variables at all!). There is a range of cases in which it's necessary or convenient to be able to refer to a GDB smob type, for instance: - Pattern matching based on the type of a value. - Defining GOOPS methods handling values from GDB (GOOPS methods typically use dynamic dispatch based on the types of the arguments). - Type-checking assertions when applying some defensive programming on an interface. - Generally any other situation one might encounter in a dynamically typed language that might need some introspection. If you're more familiar with Python, it would be quite similar to being unable to refer to the classes exported from the GDB module (which is to say: not crippling for the most part, but makes certain tasks more difficult than necessary). This commit makes a small change to GDB's smob registration machinery to make sure registered smobs get exported from the current module. This will likely cause warnings to the user about conflicting exports if they load both (gdb) and (oop goops) from a GDB linked against Guile v2.0, but it shouldn't impact functionality (and seemed preferable to trying to un-export bindings from (oop goops) if v2.0 was detected). [1]: This changed with Guile commit 28d0871b553a3959a6c59e2e4caec1c1509f8595 gdb/ChangeLog: 2021-06-07 George Barrett <bob@bob131.so> * guile/scm-gsmob.c (gdbscm_make_smob_type): Export registered smob type from the current module. gdb/testsuite/ChangeLog: 2021-06-07 George Barrett <bob@bob131.so> * gdb.guile/scm-gsmob.exp (test exports): Add tests to make sure the smob types currently listed in the GDB manual get exported from the (gdb) module. Change-Id: I7dcd791276b48dfc9edb64fc71170bbb42a6f6e7
Diffstat (limited to 'opcodes/ChangeLog')
0 files changed, 0 insertions, 0 deletions