From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28204 invoked by alias); 11 Jun 2005 15:26:14 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 28183 invoked by uid 22791); 11 Jun 2005 15:26:11 -0000 Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 11 Jun 2005 15:26:11 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id j5BFQ0oV000750; Sat, 11 Jun 2005 17:26:00 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id j5BFPxKq008639; Sat, 11 Jun 2005 17:25:59 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id j5BFPrQY001600; Sat, 11 Jun 2005 17:25:53 +0200 (CEST) Date: Sat, 11 Jun 2005 15:26:00 -0000 Message-Id: <200506111525.j5BFPrQY001600@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: msnyder@redhat.com CC: drow@false.org, gdb-patches@sources.redhat.com In-reply-to: <42927D75.4050009@redhat.com> (message from Michael Snyder on Mon, 23 May 2005 18:03:49 -0700) Subject: Re: [rfa] Restore "trust-readonly-section" References: <00c201c55745$a651dd30$aaa56b80@msnyder8600> <00e201c55748$533cea10$aaa56b80@msnyder8600> <20050515171254.GC11855@nevyn.them.org> <42927D75.4050009@redhat.com> X-SW-Source: 2005-06/txt/msg00109.txt.bz2 Date: Mon, 23 May 2005 18:03:49 -0700 From: Michael Snyder I suppose you're right -- but I'm bewildered by the number of possible entry points and paths thru this code. In theory I think I could get away with just covering three points: target_read_memory, target_read_partial, and target_read_memory_partial, were it not for the fact that do_xfer_memory is also an entry point. I'd like to make the point here that the transition from (deprecated_)xxx_xfer_memory to xxx_xfer_partial is taking us too long and that we should actively work towards removing the deprecated stuff instead of waiting for things to break. The transition state we're in now is much too confusing, at least that seems to be the case for me. Mark