From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12862 invoked by alias); 29 Apr 2009 13:07:21 -0000 Received: (qmail 12814 invoked by uid 22791); 29 Apr 2009 13:07:15 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 29 Apr 2009 13:07:08 +0000 Received: (qmail 17623 invoked from network); 29 Apr 2009 13:07:06 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 29 Apr 2009 13:07:06 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [rfc] Do not call read_pc in startup_inferior Date: Wed, 29 Apr 2009 13:07:00 -0000 User-Agent: KMail/1.9.10 Cc: "Ulrich Weigand" , Daniel Jacobowitz References: <200904291232.n3TCWuSw015927@d12av02.megacenter.de.ibm.com> In-Reply-To: <200904291232.n3TCWuSw015927@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904291407.11541.pedro@codesourcery.com> X-IsSubscribed: yes 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/msg00788.txt.bz2 On Wednesday 29 April 2009 13:32:56, Ulrich Weigand wrote: > Daniel Jacobowitz wrote: > > On Tue, Apr 28, 2009 at 06:37:12PM +0200, Ulrich Weigand wrote: > > > Hello, > > > > > > a while ago, I committed a patch to avoid calling wait_for_inferior > > > in startup_inferior, so as to avoid accessing inferior register state > > > at a time where the target's actual register layout has not yet been > > > determined (via target_find_description). > > > > > > However, startup_inferior still contains a read_pc call to retrieve > > > the initial value of stop_pc -- this of course runs into the same > > > problem. > > > > > > The patch below removes the read_pc call from startup_inferior, and > > > instead determines the initial stop_pc value in post_create_inferior, > > > after the register layout has been finalized. > > > > You're moving the call from a native "run" only routine, to an > > all-targets routine. That made me curious so I went looking... what > > relies on this setting? Anything? > > It doesn't seem a lot relies on it; the solib_create_inferior_hook > might, but this is the case only for solib-sunos.c (which I guess > could be changed to use regcache_read_pc). > > The only other potentially user-visible change seems to be that > "info program" will report "Program stopped at ..." giving the > proper entry point address. > In any case, most create_inferior implementations either call > startup_inferior, or otherwise set stop_pc e.g. by calling into > wait_for_inferior (in the latter case it shouldn't hurt to set > it again). > > There are some targets that currently do not appear to set stop_pc: > the remote-extended mode, NTO, and some monitor targets. These > would see a difference in "info program" output due to my patch > (but the new behaviour should be preferable, I guess) ... > 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 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.) -- Pedro Alves