From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22145 invoked by alias); 28 Apr 2006 18:40:00 -0000 Received: (qmail 22137 invoked by uid 22791); 28 Apr 2006 18:40:00 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 28 Apr 2006 18:39:57 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k3SIdgwN014580; Fri, 28 Apr 2006 20:39:42 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.6/8.13.6) with ESMTP id k3SIdfug013800; Fri, 28 Apr 2006 20:39:41 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.6/8.13.6/Submit) id k3SIdfsq030892; Fri, 28 Apr 2006 20:39:41 +0200 (CEST) Date: Fri, 28 Apr 2006 18:40:00 -0000 Message-Id: <200604281839.k3SIdfsq030892@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: jimb@red-bean.com CC: brobecker@adacore.com, gdb-patches@sources.redhat.com In-reply-to: <8f2776cb0604281054y116acfdavc3649dd8198d80d0@mail.gmail.com> (jimb@red-bean.com) Subject: Re: [RFC/RFA/i386] pb reading insns if breakpoints still inserted References: <20060428171154.GP17613@adacore.com> <8f2776cb0604281054y116acfdavc3649dd8198d80d0@mail.gmail.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00371.txt.bz2 > Date: Fri, 28 Apr 2006 10:54:47 -0700 > From: "Jim Blandy" > > What would folks say to simply un-deprecating > deprecated_read_memory_nobpt? We don't have an acceptable replacement > for it yet. Joel's read_insn function is the logical thing to do, but > it defeats the purpose of deprecating the function in the first place > --- encouraging people to pass context information explicitly --- to > depend on current_frame. There isn't any way at present to pull it > off. So I think the deprecation was premature. I don't completely disagree with you here, but, a different way to view the problem is putting the blame with the fact that we (ab)use the prologue analyzer for skipping the prologue when trying to place a breakpoint at the start of a function, where we really should be able to use the debug info for doing this. Currently the code is in a pretty bad shape here; some targets try to use the debug info, some use the prologue scanner and some do both. Mark