[binutils-gdb] Multi-arch exec, more register reading avoidance
sergiodj+buildbot@sergiodj.net
sergiodj+buildbot@sergiodj.net
Mon Oct 9 21:45:00 GMT 2017
*** TEST RESULTS FOR COMMIT cbd2b4e316370ab740433b06ed65786831232c8f ***
Author: Pedro Alves <palves@redhat.com>
Branch: master
Commit: cbd2b4e316370ab740433b06ed65786831232c8f
Multi-arch exec, more register reading avoidance
As mentioned in commit bf93d7ba9931 ("Add thread after updating
gdbarch when exec'ing"), we should avoid doing register reads after a
process does an exec and before we've updated that inferior's gdbarch.
Otherwise, we may interpret the registers using the wrong
architecture.
There's still (at least) one case where we still read registers
post-exec with the pre-exec architecture. That's when infrun decides
it needs to switch context to the exec'ing thread. I.e., if the exec
event is processed at a time when the current thread is not already
the exec'ing thread, then we get (with the test added by this commit):
continue
Continuing.
Truncated register 50 in remote 'g' packet
Truncated register 50 in remote 'g' packet
(gdb) FAIL: gdb.multi/multi-arch-exec.exp: selected_thread=2: follow_exec_mode=same: continue across exec that changes architecture
The fix is to avoid reading registers when switching context in this
case.
(I'd be nice to get rid of the constant stop_pc reading when switching
threads, but that'd be a deeper change.)
gdb/ChangeLog:
2017-10-09 Pedro Alves <palves@redhat.com>
* infrun.c (handle_inferior_event_1) <TARGET_WAITKIND_EXECD>: Skip
reading registers when switching context.
gdb/testsuite/ChangeLog:
2017-10-09 Pedro Alves <palves@redhat.com>
* gdb.multi/multi-arch-exec.c: Include <pthread.h> and <assert.h>.
(barrier): New.
(thread_start, all_started): New functions.
(main): Spawn new thread and wait until it is scheduled.
* gdb.multi/multi-arch-exec.exp: Build $srcfile1 with the pthreads
option.
(do_test): Add 'selected_thread' parameter. Run to all_started
instead of main. Explicitly set the breakpoint at main. Switch
to the SELECTED_THREAD thread.
(top level): Test handling the exec event with either the main
thread or the second thread selected.
More information about the Gdb-testers
mailing list