Re: [rfc] Do not call read_pc in startup_inferior

["Ulrich Weigand" <uweigand@de.ibm.com>]

Pedro Alves wrote:

> Actually, currently it is hard to stop at the entry point
> in most targets.  `proceed' will step over a breakpoint set right
> at the entry point exactly due to this stop_pc == current pc, even
> if it was never hit.  This leads to people using the "set breakpoint
> at `entry point' + 1, instead of `entry point'" trick.
> 
> Maybe we should make run_command_1
> call `proceed (current_pc, TARGET_SIGNAL_0, 0)' instead of
> `proceed (-1, TAR...)'.  This would (partially) fix the bpkt at
> entry issue, while also making sure that `proceed' isn't faced with a
> completely random random stop_pc if we pass it -1.

I see.  It seems "stop_pc" isn't really the proper mechanism for this.
(See also the problems with skipping breakpoints in multi-threaded 
applications that Doug Evans has been working on ...)

What would you think about the following replacement for stop_pc:

- Per thread, maintain a "last stop reason" state that identifies
  *where* and *why* this thread stopped.

- We skip a breakpoint whenever we're about to restart a thread and
  its "last stop reason" is "breakpoint" with an address equal to
  the restart address (and there's still a breakpoint at this location).

- In "info program", display the last stop reason of the current
  thread (or maybe all threads?). 

- In solib-sunos.c, just use regcache_read_pc.

> (I believe there are other problems that make GDB ignore
> breakpoints set at the entry point, e.g., if it happens to
> be the same place we have a BPSTAT_WHAT_CHECK_SHLIBS breakpoint.)

Hmm, if we have two breakpoints at the same address, one that is
supposed to silently restart, and one that is supposed to be
reported to the user, shouldn't the second one always "win"?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com