From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31409 invoked by alias); 25 Jun 2009 16:52:50 -0000 Received: (qmail 31401 invoked by uid 22791); 25 Jun 2009 16:52:49 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_73,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 25 Jun 2009 16:52:43 +0000 Received: from spaceape13.eur.corp.google.com (spaceape13.eur.corp.google.com [172.28.16.147]) by smtp-out.google.com with ESMTP id n5PGqdiN021254 for ; Thu, 25 Jun 2009 17:52:40 +0100 Received: from gxk6 (gxk6.prod.google.com [10.202.11.6]) by spaceape13.eur.corp.google.com with ESMTP id n5PGqCSe018812 for ; Thu, 25 Jun 2009 09:52:37 -0700 Received: by gxk6 with SMTP id 6so1631788gxk.19 for ; Thu, 25 Jun 2009 09:52:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.70.6 with SMTP id s6mr886431aga.77.1245948756959; Thu, 25 Jun 2009 09:52:36 -0700 (PDT) In-Reply-To: <20090624190346.GA17908@caradoc.them.org> References: <20090624190346.GA17908@caradoc.them.org> Date: Thu, 25 Jun 2009 16:52:00 -0000 Message-ID: Subject: Re: New breakpoint_re_set call vs remote targets From: Doug Evans To: gdb@sourceware.org, Pedro Alves , Pierre Muller Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true 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/msg00238.txt.bz2 On Wed, Jun 24, 2009 at 12:03 PM, Daniel Jacobowitz wrote: > This patch: > > 2009-06-17 =A0Pierre Muller =A0 > =A0 =A0 =A0 =A0Pedro Alves =A0 > > =A0 =A0 =A0 =A0* infcmd.c (post_create_inferior): Call breakpoint_re_set > =A0 =A0 =A0 =A0after target > =A0 =A0 =A0 =A0is pushed for watchpoint promotion to hardware watchpoint. > > causes a testcase failure in nodebug.exp for arm-none-eabi. =A0It will > affect all bare-metal targets. > > 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. "create_inferior" has a very specific connotation (at least in some contexts), and at first glance it's odd that target_remote is calling any foo_create_inferior. [Consider, for example, that "run" uses target_create_inferior, to_create_inferior is the target hook for starting programs, and target remote doesn't support "run".] The first question I had is why is target remote calling post_create_inferi= or? So I go and look at post_create_inferior, which has this: /* Common actions to take after creating any sort of inferior, by any means (running, attaching, connecting, et cetera). The target should be stopped. */ I wonder if name choices are making things harder than they should be. [Harder in the sense that bugs get inadvertently introduced, and in the sense that it's not as straightforward to reason about these things.] [Bad timing that this came up yesterday in a different context. :-)] > 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, 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? =A0Any other approaches to fix this failure? I wonder if one useful step is to reassess post_create_inferior, and maybe split it up or something. =46rom my perhaps ancient point of view, gdb is for debugging two kinds of programs: hosted and freestanding (to borrow jargon from C - though non-bare-metal and bare-metal may be more accurate. 1/2 :-)), and I wonder if they're being inadvertently fused. Or not.