From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16806 invoked by alias); 2 Sep 2008 21:55:54 -0000 Received: (qmail 16657 invoked by uid 22791); 2 Sep 2008 21:55:53 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate5.de.ibm.com (HELO mtagate5.de.ibm.com) (195.212.29.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 02 Sep 2008 21:55:07 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id m82LsGLY075200 for ; Tue, 2 Sep 2008 21:54:16 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m82LsGb04292714 for ; Tue, 2 Sep 2008 23:54:16 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m82LsGGl015973 for ; Tue, 2 Sep 2008 23:54:16 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id m82LsF4v015969; Tue, 2 Sep 2008 23:54:16 +0200 Message-Id: <200809022154.m82LsF4v015969@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 2 Sep 2008 23:54:15 +0200 Subject: Re: [rfc][23/37] Eliminate builtin_type_ macros: Platform-neutral types for internal variables To: drow@false.org (Daniel Jacobowitz) Date: Tue, 02 Sep 2008 21:55:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20080902124302.GC21700@caradoc.them.org> from "Daniel Jacobowitz" at Sep 02, 2008 08:43:02 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00030.txt.bz2 Daniel Jacobowitz wrote: > On Sun, Aug 31, 2008 at 07:51:08PM +0200, Ulrich Weigand wrote: > > One problem is the $_ variable, which holds a pointer value. To > > allow using a platform-neutral type for this, I'm introducing a > > new platform-neutral pointer type builtin_type_void_ptr. The > > lenght of this type is chosen so that it can hold every CORE_ADDR > > value. > > I don't think this is a good idea. Target-specific code should not be > required to correctly handle jumbo pointers, e.g. in "(gdb) print > foo ($_)". In a command function, we must already have some idea of > what the associated architecture is (e.g. to initialize the > architecture used by the expression evaluator); why not use that? I guess that would mean current_gdbarch for now. However, I had been wondering what that means for the multi-architecture case -- if you set $_ in one frame, and then switch to a frame using a different architecture and use $_ as inferior call argument there, we'll still get pointers the architecture doesn't understand ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com