From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22611 invoked by alias); 23 Jul 2007 19:15:50 -0000 Received: (qmail 22601 invoked by uid 22791); 23 Jul 2007 19:15:50 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 23 Jul 2007 19:15:45 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 3BBFA98301; Mon, 23 Jul 2007 19:15:45 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id B7D6398300; Mon, 23 Jul 2007 19:15:44 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1ID3Ne-0003EW-A5; Mon, 23 Jul 2007 15:15:42 -0400 Date: Mon, 23 Jul 2007 21:25:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: Joel Brobecker , gdb-patches@sourceware.org, Alex Subject: Re: [rfc] Do not read from the executable if ptrace fails Message-ID: <20070723191542.GA12138@caradoc.them.org> Mail-Followup-To: Ulrich Weigand , Joel Brobecker , gdb-patches@sourceware.org, Alex References: <20070701223533.GC337@caradoc.them.org> <200707231902.l6NJ2dJC004817@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707231902.l6NJ2dJC004817@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes 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: 2007-07/txt/msg00246.txt.bz2 On Mon, Jul 23, 2007 at 09:02:33PM +0200, Ulrich Weigand wrote: > I only noticed now, but this breaks SPU overlay support. :-( > Overlay support uses "LMA" addresses to refer to overlay sections > not currently loaded, and performs xfer_partial requests to read > from those (e.g. when invoking skip_prologue on a function not > currently present). > > This works only if accesses to those LMA addresses go through to > the xfer_memory routine in exec.c, which implements the required > logic to retrieve those section contents from the executable file. > > This used to work (probably accidentally?), but is broken by > this patch. Any suggestions how to fix it? Should the overlay > logic from xfer_memory be moved to memory_xfer_partial, maybe? That sounds reasonable. What about if we check for an unmapped overlay address at the same point we handle trust_readonly? -- Daniel Jacobowitz CodeSourcery