From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30063 invoked by alias); 30 Sep 2008 12:41:51 -0000 Received: (qmail 30042 invoked by uid 22791); 30 Sep 2008 12:41: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; Tue, 30 Sep 2008 12:41:10 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id A8F6810C30; Tue, 30 Sep 2008 12:41:07 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 6522210199; Tue, 30 Sep 2008 12:41:07 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KkeXJ-0007ei-US; Tue, 30 Sep 2008 08:41:06 -0400 Date: Tue, 30 Sep 2008 12:41:00 -0000 From: Daniel Jacobowitz To: Thiago Jung Bauermann Cc: Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [rfc] expose gdb values to python Message-ID: <20080930124105.GA29401@caradoc.them.org> Mail-Followup-To: Thiago Jung Bauermann , Eli Zaretskii , gdb-patches@sources.redhat.com References: <20080921042657.GB29631@caradoc.them.org> <20080925114659.GA30878@caradoc.them.org> <1222704906.8567.45.camel@localhost.localdomain> <20080929165930.GA19283@caradoc.them.org> <1222747562.8567.87.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1222747562.8567.87.camel@localhost.localdomain> 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/msg00569.txt.bz2 On Tue, Sep 30, 2008 at 01:06:02AM -0300, Thiago Jung Bauermann wrote: > I did it this way having in mind the case when a value needs to be > created at a moment when no file is loaded (and thus an > architecture/target is not yet determined). This is the same problem > faced by the expression evaluator, when the user types (say): > > (gdb) print 1.2 And I think it should have the same solution. There's a default architecture for these cases (depending on how GDB was built). If, in the future, we find another way to handle the print command... then we can find another way to handle this, too. I suggest that rather than bending over backwards to avoid the gdbarch. -- Daniel Jacobowitz CodeSourcery