From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25195 invoked by alias); 14 Mar 2010 16:21:17 -0000 Received: (qmail 25186 invoked by uid 22791); 14 Mar 2010 16:21:16 -0000 X-SWARE-Spam-Status: No, hits=-2.6 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; Sun, 14 Mar 2010 16:21:11 +0000 Received: (qmail 17089 invoked from network); 14 Mar 2010 16:21:10 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Mar 2010 16:21:10 -0000 Date: Sun, 14 Mar 2010 16:21:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sourceware.org Cc: Joel Brobecker , Pedro Alves Subject: [RFC/7.1] Reset breakpoints after load Message-ID: <20100314162107.GG9310@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) 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/msg00497.txt.bz2 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. * 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. * 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. I'd like to do the long-term solution also, but it will take longer than the 7.1 release. -- Daniel Jacobowitz CodeSourcery 2010-03-14 Daniel Jacobowitz * symfile.c (generic_load): Reset breakpoints after loading. --- gdb/symfile.c | 10 ++++++++++ 1 file changed, 10 insertions(+) Index: gdb-mainline/gdb/symfile.c =================================================================== --- gdb-mainline.orig/gdb/symfile.c 2010-03-11 00:23:57.000000000 -0800 +++ gdb-mainline/gdb/symfile.c 2010-03-14 08:45:43.000000000 -0700 @@ -1890,6 +1890,16 @@ generic_load (char *args, int from_tty) for other targets too. */ regcache_write_pc (get_current_regcache (), entry); + /* Reset breakpoints. This should not be necessary, but it is + needed because of two other factors. One is that + post_create_inferior calls breakpoint_re_set, so breakpoints were + already reset when we connected to the target. The other is that + prologue analyzers read memory from the target, even though they + rely on the symbol table too. So when we reset breakpoints after + connection, we may have read uninitialized memory from the + target. */ + breakpoint_re_set (); + /* FIXME: are we supposed to call symbol_file_add or not? According to a comment from remote-mips.c (where a call to symbol_file_add was commented out), making the call confuses GDB if more than one