Fix follow-exec regression / crash

Fix follow-exec regression / crash

After commit 00431a78b28f ("Use thread_info and inferior pointers more
throughout"), following an exec can result in gdb crashing.  On some
systems, this is visible with gdb.multi/multi-arch-exec.exp and
gdb.base/foll-exec-mode.exp.  E.g.:

  $ make check TESTS="gdb.multi/multi-arch-exec.exp gdb.base/foll-exec-mode.exp"
  [snip]
  FAIL: gdb.multi/multi-arch-exec.exp: first_arch=1: selected_thread=1: follow_exec_mode=new: continue across exec that changes architecture (GDB internal error)
  ERROR: : spawn id exp10 not open
      while executing

Running multi-arch-exec under Valgrind we easily spot the problem:

  process 16305 is executing new program: ..../gdb.multi/multi-arch-exec/1-multi-arch-exec-hello
  [New inferior 2 (process 0)]
  [New process 16305]
  ==16129== Invalid read of size 8
  ==16129==    at 0x7FA14D: get_thread_regcache(thread_info*) (regcache.c:399)
  ==16129==    by 0x75E54B: handle_inferior_event_1(execution_control_state*) (infrun.c:5292)
  ==16129==    by 0x75E82D: handle_inferior_event(execution_control_state*) (infrun.c:5382)
  ==16129==    by 0x75BC6A: fetch_inferior_event(void*) (infrun.c:3918)
  ==16129==    by 0x748DA3: inferior_event_handler(inferior_event_type, void*) (inf-loop.c:43)
  ==16129==    by 0x464B5D: handle_target_event(int, void*) (linux-nat.c:4359)
  ==16129==    by 0x7047E0: handle_file_event(file_handler*, int) (event-loop.c:733)
  ==16129==    by 0x704D83: gdb_wait_for_event(int) (event-loop.c:859)
  ==16129==    by 0x703BF6: gdb_do_one_event() (event-loop.c:322)
  ==16129==    by 0x703CA2: start_event_loop() (event-loop.c:371)
  ==16129==    by 0x791D95: captured_command_loop() (main.c:330)
  ==16129==    by 0x79311C: captured_main(void*) (main.c:1157)
  ==16129==  Address 0x15a5bad0 is 32 bytes inside a block of size 600 free'd
  ==16129==    at 0x4C2E1E8: operator delete(void*) (vg_replace_malloc.c:576)
  ==16129==    by 0x8A15D0: delete_thread_1(thread_info*, bool) (thread.c:465)
  ==16129==    by 0x8A15FA: delete_thread(thread_info*) (thread.c:476)
  ==16129==    by 0x8A0D43: add_thread_silent(ptid_t) (thread.c:291)
  ==16129==    by 0x8A0DF0: add_thread_with_info(ptid_t, private_thread_info*) (thread.c:317)
  ==16129==    by 0x8A0E79: add_thread(ptid_t) (thread.c:331)
  ==16129==    by 0x75764C: follow_exec(ptid_t, char*) (infrun.c:1233)
  ==16129==    by 0x75E534: handle_inferior_event_1(execution_control_state*) (infrun.c:5290)
  ==16129==    by 0x75E82D: handle_inferior_event(execution_control_state*) (infrun.c:5382)
  ==16129==    by 0x75BC6A: fetch_inferior_event(void*) (infrun.c:3918)
  ==16129==    by 0x748DA3: inferior_event_handler(inferior_event_type, void*) (inf-loop.c:43)
  ==16129==    by 0x464B5D: handle_target_event(int, void*) (linux-nat.c:4359)

The problem is that handle_inferior_event_1 is reading the stop_pc off
of a thread that was deleted by follow_exec.  Before commit
00431a78b28f, we didn't crash because we were passing down a ptid to
get_thread_regcache instead of ecs->event_thread.

Fix this by simply moving the stop_pc reading until after
ecs->event_thread is refreshed.

gdb/ChangeLog:
2018-06-28  Pedro Alves  <palves@redhat.com>

	* infrun.c (handle_inferior_event_1) <TARGET_WAITKIND_EXECD>:
	Moving fetching stop_pc until after ecs->event_thread is refreshed.