From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19721 invoked by alias); 4 Sep 2008 12:15:50 -0000 Received: (qmail 19713 invoked by uid 22791); 4 Sep 2008 12:15:49 -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; Thu, 04 Sep 2008 12:15:02 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id ECC6298418; Thu, 4 Sep 2008 12:15:00 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id A973A98417; Thu, 4 Sep 2008 12:15:00 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KbDjn-0007Fi-Kn; Thu, 04 Sep 2008 08:14:59 -0400 Date: Thu, 04 Sep 2008 12:15:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: gdb-patches@sourceware.org, pedro@codesourcery.com Subject: Re: [rfc] Displaced stepping with wrong entry point address Message-ID: <20080904121459.GB27200@caradoc.them.org> Mail-Followup-To: Ulrich Weigand , gdb-patches@sourceware.org, pedro@codesourcery.com References: <200808221748.m7MHmkpd004832@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200808221748.m7MHmkpd004832@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.17 (2008-05-11) 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: 2008-09/txt/msg00063.txt.bz2 On Fri, Aug 22, 2008 at 07:48:46PM +0200, Ulrich Weigand wrote: > I'm wondering whether this fix would be good for the general case too > -- there may be situations where entry_point_address does not work > (e.g. because the main executable file could not be loaded). The > auxiliary vector, on targets where it is present, will probably be > more reliable ... We really ought to cache this value; you'll go back and forth to the target to read the auxv vector at every singlestep. If SPU ever did support displaced stepping (not that this would be terribly useful, but consider some other multi-architecture case), would this be wrong for the SPU side code? -- Daniel Jacobowitz CodeSourcery