diff options
author | George Barrett <bob@bob131.so> | 2021-06-07 04:49:58 +1000 |
---|---|---|
committer | Simon Marchi <simon.marchi@polymtl.ca> | 2021-08-09 23:20:41 -0400 |
commit | c173cc8a666792a6e864b5beb1c4d6903169b5cd (patch) | |
tree | c928c8551cbf87757017b0f872b606e9906d429e /opcodes/ChangeLog | |
parent | d2a2c939f187a595fc7ccdac0ffbbab1d39e9d5b (diff) | |
download | gdb-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