From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2192 invoked by alias); 24 Jun 2009 23:36:29 -0000 Received: (qmail 2183 invoked by uid 22791); 24 Jun 2009 23:36:29 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_73,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, 24 Jun 2009 23:36:20 +0000 Received: (qmail 7258 invoked from network); 24 Jun 2009 23:36:18 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 24 Jun 2009 23:36:18 -0000 From: Pedro Alves To: Daniel Jacobowitz Subject: Re: New breakpoint_re_set call vs remote targets Date: Wed, 24 Jun 2009 23:36:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb@sourceware.org, Pierre Muller References: <20090624190346.GA17908@caradoc.them.org> In-Reply-To: <20090624190346.GA17908@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906250037.17148.pedro@codesourcery.com> 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/msg00229.txt.bz2 On Wednesday 24 June 2009 20:03:46, Daniel Jacobowitz wrote: > This patch: >=20 > 2009-06-17 =A0Pierre Muller =A0 > =A0 =A0 =A0 =A0 Pedro Alves =A0 >=20 > =A0 =A0 =A0 =A0 * infcmd.c (post_create_inferior): Call breakpoint_re_set > =A0=A0=A0=A0=A0=A0=A0=A0after target > =A0 =A0 =A0 =A0 is pushed for watchpoint promotion to hardware watchpoint. >=20 > causes a testcase failure in nodebug.exp for arm-none-eabi. =A0It will > affect all bare-metal targets. >=20 > The sequence is "target remote", which calls post_create_inferior > before any program exists on the remote side. =A0Then later "load" fills > in the code. =A0So we're doing prologue skipping - by reading target > memory - before we've written the code to target memory. 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). 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). >=20 > I have long had a plan to speed up prologue skipping by making it read > directly from the executable if possible. =A0We're using the > executable's symbol table, so there's no reason to think the prologue > will have moved around on the target. =A0The problems with this approach > are (A) it involves changing a lot of symbol readers,=20 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=20 > 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. > Thoughts? =A0Any 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. But, what was the real failure? It also occurs to me that for always-inserted mode, we'd probably want to uninsert breakpoints before loading. --=20 Pedro Alves