Fix follow_exec latent problem

A following commit to make each inferior have its own thread list
exposes a problem with bf93d7ba99 ("Add thread after updating gdbarch
when exec'ing"), which is that we can't defer adding the thread
because that breaks try_open_exec_file which deep inside ends up
calling inferior_thread():

 #5  0x0000000000637c78 in internal_error(char const*, int, char const*, ...) (file=0xc151f8 "src/gdb/thread.c", line=165, fmt=0xc15180 "%s: Assertion `%s' failed.") at src/gdb/common/errors.c:55
 #6  0x00000000008a3d80 in inferior_thread() () at src/gdb/thread.c:165
 #7  0x0000000000456f91 in try_thread_db_load_1(thread_db_info*) (info=0x277eb00) at src/gdb/linux-thread-db.c:830
 #8  0x0000000000457554 in try_thread_db_load(char const*, int) (library=0xb01a4f "libthread_db.so.1", check_auto_load_safe=0)
     at src/gdb/linux-thread-db.c:1002
 #9  0x0000000000457861 in try_thread_db_load_from_sdir() () at src/gdb/linux-thread-db.c:1079
 #10 0x0000000000457b72 in thread_db_load_search() () at src/gdb/linux-thread-db.c:1134
 #11 0x0000000000457d29 in thread_db_load() () at src/gdb/linux-thread-db.c:1192
 #12 0x0000000000457e51 in check_for_thread_db() () at src/gdb/linux-thread-db.c:1244
 #13 0x0000000000457ed2 in thread_db_new_objfile(objfile*) (objfile=0x270ff60) at src/gdb/linux-thread-db.c:1273
 #14 0x000000000045a92e in std::_Function_handler<void (objfile*), void (*)(objfile*)>::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7ffef3efe140: 0x270ff60) at /usr/include/c++/7/bits/std_function.h:316
 #15 0x00000000007bbebf in std::function<void (objfile*)>::operator()(objfile*) const (this=0x24e1d18, __args#0=0x270ff60)
     at /usr/include/c++/7/bits/std_function.h:706
 #16 0x00000000007bba86 in gdb::observers::observable<objfile*>::notify(objfile*) const (this=0x117ce80 <gdb::observers::new_objfile>, args#0=0x270ff60) at src/gdb/common/observable.h:106
 #17 0x0000000000856000 in symbol_file_add_with_addrs(bfd*, char const*, symfile_add_flags, section_addr_info*, objfile_flags, objfile*) (abfd=0x1d7dae0, name=0x254bfc0 "/ho

The problem is latent currently because inferior_thread() at that
point manages to return a thread, even though it's the wrong one (of
the old inferior).

The problem originally fixed by bf93d7ba99 was:

    (...) 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.

    (...) The call to "add_thread" done just after adding the inferior is
    problematic, because it ends up reading the registers (because the ptid
    is re-used, we end up doing a switch_to_thread to it, which tries to
    update stop_pc). (...)

The register-reading issue is no longer a problem nowadays, ever since
switch_to_thread stopped reading the stop_pc in git commit
f2ffa92bbc ("gdb: Eliminate the 'stop_pc' global").

So this commit basically reverts bf93d7ba99.

gdb/ChangeLog:
2018-11-22  Pedro Alves  <palves@redhat.com>

	* infrun.c (follow_exec) <set follow-exec new>: Add thread and
	switch to it before calling into try_open_exec_file.
This commit is contained in:
Pedro Alves 2018-11-22 16:09:12 +00:00
parent 151bb4a505
commit c4c17fb0f5
2 changed files with 6 additions and 5 deletions

View File

@ -1,3 +1,8 @@
2018-11-22 Pedro Alves <palves@redhat.com>
* infrun.c (follow_exec) <set follow-exec new>: Add thread and
switch to it before calling into try_open_exec_file.
2018-11-22 Pedro Alves <palves@redhat.com>
* cli/cli-interp.c (cli_on_user_selected_context_changed): Use

View File

@ -1202,6 +1202,7 @@ follow_exec (ptid_t ptid, char *exec_file_target)
set_current_inferior (inf);
set_current_program_space (inf->pspace);
add_thread (ptid);
}
else
{
@ -1231,11 +1232,6 @@ follow_exec (ptid_t ptid, char *exec_file_target)
registers. */
target_find_description ();
/* The add_thread call ends up reading registers, so do it after updating the
target description. */
if (follow_exec_mode_string == follow_exec_mode_new)
add_thread (ptid);
solib_create_inferior_hook (0);
jit_inferior_created_hook ();