From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30002 invoked by alias); 30 Apr 2009 14:27:26 -0000 Received: (qmail 29992 invoked by uid 22791); 30 Apr 2009 14:27:24 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate5.de.ibm.com (HELO mtagate5.de.ibm.com) (195.212.29.154) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 30 Apr 2009 14:27:19 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.14.3/8.13.8) with ESMTP id n3UEPPL6097894 for ; Thu, 30 Apr 2009 14:25:25 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n3UEPOKh1585378 for ; Thu, 30 Apr 2009 16:25:24 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n3UEPN3J019892 for ; Thu, 30 Apr 2009 16:25:24 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id n3UEPMhk019694; Thu, 30 Apr 2009 16:25:22 +0200 Message-Id: <200904301425.n3UEPMhk019694@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 30 Apr 2009 16:25:17 +0200 Subject: Re: [rfc] Do not call read_pc in startup_inferior To: pedro@codesourcery.com (Pedro Alves) Date: Thu, 30 Apr 2009 14:27:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, drow@false.org (Daniel Jacobowitz) In-Reply-To: <200904291407.11541.pedro@codesourcery.com> from "Pedro Alves" at Apr 29, 2009 02:07:11 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-04/txt/msg00809.txt.bz2 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