Sporadically the new execl.exp test fails with:

Executing new program: /home/pedro/gdb/execl_hunt/build32/gdb/testsuite/gdb.threads/execl1
Error in re-setting breakpoint 2: No source file named ../../../src/gdb/testsuite/gdb.threads/execl.c.
warning: Cannot initialize thread debugging library: versions of libpthread and libthread_db do not match
/home/pedro/gdb/execl_hunt/build32/gdb/testsuite/gdb.threads/execl1: error while loading shared libraries: libc.so.6:
failed to map segment from shared object: Cannot allocate memory

Program exited with code 0177.
(gdb) FAIL: gdb.threads/execl.exp: continue across exec (the program exited)

I traced to problem into the fact that when thread_db is loaded, GDB
will delete a breakpoint that was inserted in the old image from the
new image, which is a bad thing.  The breakpoint shadows of the old
image are meaningless for the new image.

There's a call to mark_breakpoints_out in update_breakpoints_after_exec, which is
called by follow_exec, which in turn is called by handle_inferior_event on
a TARGET_WAITKIND_EXECD, that takes care of marking all breakpoints as not
inserted, to present this case.

The problem starts here:

static ptid_t
thread_db_wait (ptid_t ptid, struct target_waitstatus *ourstatus)
{
  ptid = target_beneath->to_wait (ptid, ourstatus);

  (...)

  if (ourstatus->kind == TARGET_WAITKIND_EXECD)
    {
      remove_thread_event_breakpoints (); <<<<<
      unpush_target (&thread_db_ops);
      using_thread_db = 0;

      return ptid;
    }

remove_thread_event_breakpoints calls delete_breakpoint,
and this happens before reaching handle_inferior_event, hence at this
point, the breakpoints that were inserted in the old image are still
mark as such, which triggers the breakpoint shadows to be inserted
into the new exec image.

It is my opition, that defering the mark_breakpoints_out call to so
late out of the target is not safe.  It is better to calls it as
soon as we detect that the inferior execed.

That is what the attached patch does.

Tested on x86_64-unknown-linux-gnu.  I no longer get sporadic
failures on execl.exp.  They were much easier to trigger with
-m32 for some reason).

breakpoints always-inserted mode requires yet another fix,
which I'll post in a sec.

-- 
Pedro Alves