diff options
author | Andrew Burgess <andrew.burgess@embecosm.com> | 2021-03-12 11:07:19 +0000 |
---|---|---|
committer | Andrew Burgess <andrew.burgess@embecosm.com> | 2021-03-15 09:21:37 +0000 |
commit | ba6a0ef34933712ec65855997e982bead3b314d4 (patch) | |
tree | 3e2266ac864cec209509e064b85c6a4dec9dd204 /ld/pe-dll.c | |
parent | e838b3ca2172f275e05b098adf48a36bda6348b3 (diff) | |
download | gdb-ba6a0ef34933712ec65855997e982bead3b314d4.zip gdb-ba6a0ef34933712ec65855997e982bead3b314d4.tar.gz gdb-ba6a0ef34933712ec65855997e982bead3b314d4.tar.bz2 |
gdb: use make_scoped_restore to restore gdbpy_current_objfile
The current mechanism by which the Python gdb.current_objfile is
maintained does not allow for nested auto-load events. It is assumed
that once an auto-load script has finished loading then the current
objfile should be set back to NULL. In a nested situation, we should
be restoring the previous value.
We already have an RAII class to handle save/restore type behaviour,
so lets just switch to use that.
The test is a little contrived, but is simple enough, and triggers the
bug. The real use case might involve the auto-load script calling
functions (either in the just-loaded object file, or in the main
executable), which in turn trigger further auto-loads to occur.
gdb/ChangeLog:
* python/python.c (gdbpy_source_objfile_script): Use
make_scoped_restore to restore gdbpy_current_objfile.
(gdbpy_execute_objfile_script): Likewise.
gdb/testsuite/ChangeLog:
* gdb.python/py-auto-load-chaining-f1.c: New file.
* gdb.python/py-auto-load-chaining-f1.o-gdb.py: New file.
* gdb.python/py-auto-load-chaining-f2.c: New file.
* gdb.python/py-auto-load-chaining-f2.o-gdb.py: New file.
* gdb.python/py-auto-load-chaining.c: New file.
* gdb.python/py-auto-load-chaining.exp: New file.
Diffstat (limited to 'ld/pe-dll.c')
0 files changed, 0 insertions, 0 deletions