From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29094 invoked by alias); 17 Dec 2007 17:47:04 -0000 Received: (qmail 29077 invoked by uid 22791); 17 Dec 2007 17:47:02 -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, 17 Dec 2007 17:46:50 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 52B9E98129; Mon, 17 Dec 2007 17:46:47 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 14DFA98100; Mon, 17 Dec 2007 17:46:47 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1J4K3B-0001gn-RD; Mon, 17 Dec 2007 12:46:45 -0500 Date: Mon, 17 Dec 2007 17:50:00 -0000 From: Daniel Jacobowitz To: "Maciej W. Rozycki" Cc: gdb-patches@sourceware.org, Nigel Stephens , "Maciej W. Rozycki" Subject: Re: utils.c: Sign-extend addresses if required by the target Message-ID: <20071217174645.GA6476@caradoc.them.org> Mail-Followup-To: "Maciej W. Rozycki" , gdb-patches@sourceware.org, Nigel Stephens , "Maciej W. Rozycki" References: <20071216213324.GB2618@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-12-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: 2007-12/txt/msg00277.txt.bz2 On Mon, Dec 17, 2007 at 05:37:44PM +0000, Maciej W. Rozycki wrote: > On Sun, 16 Dec 2007, Daniel Jacobowitz wrote: > > > OK. This routine is used by MI, but should not be - a long term TODO > > item is to change the way we present frame IDs to MI frontends to not > > be based on the stack pointer, and then its use will go away. But > > that's not going to happen too soon. > > What about Insight? Not that I would die for it, but the function is > called from a few places in gdbtk/generic/gdbtk-{cmds,stack,varobj}.c and > given the amount of development done on Insight these days I would imagine > these uses are not going to go away anytime soon. Right. I'm not going to touch it; I don't know what Insight uses it for, or whether it should. But it's probably using it for the same reason MI is, since Insight predates varobjs. I try not to break Insight knowingly, but if we go to clean up MI frame identification and that breaks Insight, I'll leave it to the Insight developers to clean up. That's the downside of being so tightly tied into GDB. -- Daniel Jacobowitz CodeSourcery