This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] Do not call read_pc in startup_inferior
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: pedro at codesourcery dot com (Pedro Alves)
- Cc: gdb-patches at sourceware dot org, drow at false dot org (Daniel Jacobowitz)
- Date: Thu, 30 Apr 2009 16:25:17 +0200 (CEST)
- Subject: Re: [rfc] Do not call read_pc in startup_inferior
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