The flag `inserted' in bp loc is not managed correctly in the case that
gdb gets reply from gdbserver on packet "qOffset".

In order to illustrate this problem clearly, here is a simple callgraph,

remote_start_remote
  |
  +-> get_offsets
  |     |
  |     `-> objfile_relocate // if gdbserver replies offsets
  |           |
  |           `-> breakpoint_re_set//[1] insert bp and loc->inserted = 1
  |
  `-> start_remote
        |
        +-> init_wait_for_inferior
        |     |
        |     `-> breakpoint_init_inferior //[2] loc->inserted = 0
        |
        `-> post_create_inferior
              |
              `-> breakpoint_re_set//[3] insert bp again, and
loc-inserted = 1

Supposing we have inserted an breakpoint B on address A1 before any
target is created.  Then, we create a target remote.  When gdbserver
replies qOffset packet with an offset map (usually, in uclinux,
gdbserver will do this), objfile_relocate is called, and
breakpoint_re_set [1] is called, so breakpoint B is inserted on address
A2, which is the relocated address of A1.  Then, in [2],
breakpoint_init_inferior is called, so the bp loc corresponding to B is
reset, and flag `inserted' is set to zero.  Finally, when goes to
post_create_inferior, breakpoint_re_set is called, since breakpoint B's
loc's flag `inserted' has been zero (cleaned in [2]), gdb will insert
breakpoint again at the same address A2, however breakpoint instruction
has on address A2.  gdb will read breakpoint instruction into shadow,
and store the same breakpoint instruction on address A2.  The original
instruction is lost!.

The cause of this problem is breakpoint_init_inferioris called later
than breakpoint_re_set.  This patch is to move init_wait_for_inferior
forward, so that it can be called before breakpoint_re_set.

This problem is revealed by following fail in my uclinux port, and this
patch fixes this fail.

  FAIL: gdb.base/break-always.exp: continue to breakpoint: bar

This patch is regression tested on x86_64-known-linux with board file
native-gdbserver.exp as well.  Although there are some mi tests PASSes
and FAILs(timeout), they are caused by instable tests, instead of my patch.

I am still not very familiar with infrun.c and remote.c, so comments are
welcome.

-- 
Yao (齐尧)