From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29035 invoked by alias); 24 Jun 2009 19:04:07 -0000 Received: (qmail 29009 invoked by uid 22791); 24 Jun 2009 19:04:01 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_73 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 19:03:50 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 370721053D; Wed, 24 Jun 2009 19:03:48 +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 F2E261053C; Wed, 24 Jun 2009 19:03:47 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1MJXl4-0004kT-Nh; Wed, 24 Jun 2009 15:03:46 -0400 Date: Wed, 24 Jun 2009 19:04:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org, Pedro Alves , Pierre Muller Subject: New breakpoint_re_set call vs remote targets Message-ID: <20090624190346.GA17908@caradoc.them.org> Mail-Followup-To: gdb@sourceware.org, Pedro Alves , Pierre Muller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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/msg00227.txt.bz2 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. causes a testcase failure in nodebug.exp for arm-none-eabi. It will affect all bare-metal targets. The sequence is "target remote", which calls post_create_inferior before any program exists on the remote side. Then later "load" fills in the code. So we're doing prologue skipping - by reading target memory - before we've written the code to target memory. I have long had a plan to speed up prologue skipping by making it read directly from the executable if possible. We're using the executable's symbol table, so there's no reason to think the prologue will have moved around on the target. The problems with this approach are (A) it involves changing a lot of symbol readers, 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. Thoughts? Any other approaches to fix this failure? -- Daniel Jacobowitz CodeSourcery