From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8644 invoked by alias); 24 Jun 2009 23:46:44 -0000 Received: (qmail 8636 invoked by uid 22791); 24 Jun 2009 23:46:43 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 24 Jun 2009 23:46:37 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id B90211053D; Wed, 24 Jun 2009 23:46:35 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id 937FA1053C; Wed, 24 Jun 2009 23:46:35 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1MJcAk-0006Mn-Qb; Wed, 24 Jun 2009 19:46:34 -0400 Date: Wed, 24 Jun 2009 23:46:00 -0000 From: Daniel Jacobowitz To: Pedro Alves Cc: gdb@sourceware.org, Pierre Muller Subject: Re: New breakpoint_re_set call vs remote targets Message-ID: <20090624234634.GA24279@caradoc.them.org> Mail-Followup-To: Pedro Alves , gdb@sourceware.org, Pierre Muller References: <20090624190346.GA17908@caradoc.them.org> <200906250037.17148.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200906250037.17148.pedro@codesourcery.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00230.txt.bz2 On Thu, Jun 25, 2009 at 12:37:16AM +0100, Pedro Alves wrote: > What does the failure look like? I assume that either prologue > skipping just doesn't skip anything meaningful and the breakpoint > ends up set at the beginning of the garbage "prologue"; or, some exception > is thrown (I'd argue that prologue skipping shouldn't throw in this case). The memory happens to be mostly zero at this point. The zero pattern in Thumb mode is lsl r0, #0 (from memory, don't shoot me if I'm wrong). That's a nop - which the prologue skipper happily skips. In fact, in one case it keeps skipping right past the end of the function. (This is nodebug.exp.) > This sounds like something that has always been broken, but we > didn't notice due to the fact that nothing happens pulls symbols > between "target remote" and "load" on those configurations: e.g., > from your description, target remote; add-symbol-file; load; > should be failing even before that patch? (given that add-symbol-file > triggers a breakpoint reset). Probably so, but in practice it rarely ever triggered before now. Now it happens all the time, although it's mitigated by debug info; we'll use that for prologue skipping instead. > Yeah, this could hacked by forcing trust-readonly-sections in > some places. This and address spaces have made me think before that > to_xfer_partial may be a too stiff interface for memory reads > (in that we may end up reviving deprecated_xfer_memory...). > > > and (B) I'm not > > sure if we want to handle fix-and-continue style function patching in > > which case we need to read from the target anyway. > > Right. That's the main counter-point. Curious what folks think of the tradeoff here. > > Thoughts?  Any other approaches to fix this failure? > > Assuming the debugging session didn't blow up, wouldn't a > breakpoint_re_set call after loading fix this? The live > target has gotten new code loaded, so triggering > breakpoint re-evaluation and prologue skipping doesn't sound > wrong to me. Yeah, that would probably do it. I think it's wacky that prologue skipping relies on target memory, though. > It also occurs to me that for always-inserted mode, we'd probably > want to uninsert breakpoints before loading. Uck. -- Daniel Jacobowitz CodeSourcery