From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26484 invoked by alias); 15 Mar 2010 19:27:14 -0000 Received: (qmail 26476 invoked by uid 22791); 15 Mar 2010 19:27:13 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Mar 2010 19:27:09 +0000 Received: (qmail 8929 invoked from network); 15 Mar 2010 19:27:07 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 15 Mar 2010 19:27:07 -0000 From: Pedro Alves To: Daniel Jacobowitz Subject: Re: [RFC/7.1] Reset breakpoints after load Date: Mon, 15 Mar 2010 19:27:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-19-generic; KDE/4.3.2; x86_64; ; ) Cc: gdb-patches@sourceware.org, Joel Brobecker References: <20100314162107.GG9310@caradoc.them.org> In-Reply-To: <20100314162107.GG9310@caradoc.them.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003151927.06019.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: 2010-03/txt/msg00557.txt.bz2 On Sunday 14 March 2010 16:21:07, Daniel Jacobowitz wrote: > Since this patch: > > 2009-06-17 Pierre Muller > Pedro Alves > > * infcmd.c (post_create_inferior): Call breakpoint_re_set after target > is pushed for watchpoint promotion to hardware watchpoint. > > GDB performs this sequence: > > % gdb -quiet file > (gdb) break main > [Breakpoint set after prologue] > (gdb) target remote :PORT > [Connect to remote target] > [breakpoint_re_set called] > (gdb) load > (gdb) continue > > If the prologue skipping logic reads from memory, then when > breakpoint_re_set is called, it will read garbage. Many of the > prologue analyzers do, although the effect is mitigated by > skip_prologue_using_sal, which is used in preference if possible. > > I believe we worked around this bug locally for MIPS. I've also just > encountered it while testing a patch for ARM that changes the prologue > skipping behavior. > > I can think of three solutions. > > * Don't reset breakpoints here. Promote watchpoints and make no other > changes. A bit twisty to implement, unfortunately. This would only papers over the issue. Imagine that the patch that introduced the new breakpoint_re_set call was reverted. You can still trigger the issue at hand easily. E.g.: $ gdb (gdb) target remote :PORT [Connect to remote target] (gdb) file FILE [breakpoint_re_set called] (gdb) load (gdb) continue > > * Don't read from the target during prologue analyzers; only read from > the executable file. I like this solution best, and it has other > merits (it's faster!). But it's the most work. "only" would be too strong. You'd want "prefer", like trust-readonly-sections. We may have debug info available but no pure memory contents to read from. > * The easy solution: Reset breakpoints again once we know that target > memory is valid. > > Any comments on this patch? It has no effect on test results on > arm-none-eabi today, and fixes two hundred or so failures with another > patch that required reading from the target during prologue analysis. Given that I proposed exactly this at least a couple of times already, I don't expect you to be waiting for me to say go ahead. :-) I'm not sure I agree in calling this a workaround though. IMO, this situation is analog to an "exec". The previous memory image is supposedly replaced by "load". Consider breakpoints always-inserted mode: the previous traps are simply overwriten by "load" behind the breakpoint's module. Calling: - mark_breakpoints_out (); - update_breakpoints_after_exec (); - breakpoint_re_set (); Wouldn't be such a stretch, although just - remove_breakpoints (); - breakpoint_re_set (); would work too, and be simpler. The comment reads a bit like the post_create_inferior path is the only that causes this, but as shown in the example abov , any breakpoint_re_set call would trigger the issue, so maybe I'd rephrase it a bit in that direction. IMO. -- Pedro Alves