aboutsummaryrefslogtreecommitdiff
path: root/ld/pe-dll.c
diff options
context:
space:
mode:
authorAndrew Burgess <andrew.burgess@embecosm.com>2021-03-12 11:07:19 +0000
committerAndrew Burgess <andrew.burgess@embecosm.com>2021-03-15 09:21:37 +0000
commitba6a0ef34933712ec65855997e982bead3b314d4 (patch)
tree3e2266ac864cec209509e064b85c6a4dec9dd204 /ld/pe-dll.c
parente838b3ca2172f275e05b098adf48a36bda6348b3 (diff)
downloadgdb-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