From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24024 invoked by alias); 2 Sep 2008 22:02:42 -0000 Received: (qmail 24008 invoked by uid 22791); 2 Sep 2008 22:02:41 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate1.de.ibm.com (HELO mtagate1.de.ibm.com) (195.212.17.161) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 02 Sep 2008 22:01:58 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.1/8.13.1) with ESMTP id m82M1t7Z018913 for ; Tue, 2 Sep 2008 22:01:55 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 m82M1tlR1683512 for ; Wed, 3 Sep 2008 00:01:55 +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 m82M1tkL021070 for ; Wed, 3 Sep 2008 00:01:55 +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 m82M1t8q021067; Wed, 3 Sep 2008 00:01:55 +0200 Message-Id: <200809022201.m82M1t8q021067@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 3 Sep 2008 00:01:55 +0200 Subject: Re: [rfc][00/37] Eliminate builtin_type_ macros To: drow@false.org (Daniel Jacobowitz) Date: Tue, 02 Sep 2008 22:02:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20080902124921.GE21700@caradoc.them.org> from "Daniel Jacobowitz" at Sep 02, 2008 08:49:21 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/msg00033.txt.bz2 Daniel Jacobowitz wrote: > On Sun, Aug 31, 2008 at 07:50:45PM +0200, Ulrich Weigand wrote: > > What do you think? > > All the others I didn't respond to look OK to me. Thanks for looking over them! > I'm mildly > concerned about the contortions you had to go through; it becomes hard > to get at the architecture in new places. But we'll have to see how > that works out in practice. To some extent, there is a choice of direction here. Today, we have a number of low-level routines that have implicit dependency on the "current" architecture. To fix this, there are really two directions: - Re-define the lower-level parts to be architecture-independent, and push architecture-dependent semantics up. or - Make lower-level entities *explicitly* architecture-specific For example, should a "value" be platform-neutral or platform-specific? If value is platform-neutral, we'll need to take explicit care at the locations where values get in contact with platform-specific code, e.g. when loading/storing from target memory. If value is platform-specific, it should probably carry an explicit gdbarch pointer. Then we can -in a multi-arch setting- get into the situation what to do with values of a different architecture than the current frame ... With this patch-set, I've made "expression" explicitly platform-specific, but tried to keep "value" and "type" more platform-independent. I guess we'll have to see if this is right choice. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com