From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4060 invoked by alias); 2 Sep 2008 21:48:47 -0000 Received: (qmail 4049 invoked by uid 22791); 2 Sep 2008 21:48:46 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate8.de.ibm.com (HELO mtagate8.de.ibm.com) (195.212.29.157) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 02 Sep 2008 21:48:00 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate8.de.ibm.com (8.13.8/8.13.8) with ESMTP id m82Ll8U0568976 for ; Tue, 2 Sep 2008 21:47:08 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 m82Ll88v3219506 for ; Tue, 2 Sep 2008 23:47:08 +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 m82Ll8DM011964 for ; Tue, 2 Sep 2008 23:47:08 +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 m82Ll8Td011960; Tue, 2 Sep 2008 23:47:08 +0200 Message-Id: <200809022147.m82Ll8Td011960@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 2 Sep 2008 23:47:08 +0200 Subject: Re: [rfc][08/37] Eliminate builtin_type_ macros: Make pointer arithmetic explicit To: drow@false.org (Daniel Jacobowitz) Date: Tue, 02 Sep 2008 21:48:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20080902123738.GB21700@caradoc.them.org> from "Daniel Jacobowitz" at Sep 02, 2008 08:37:38 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/msg00027.txt.bz2 Daniel Jacobowitz wrote: > > This moves the type to be used for pointer difference operations up > > eval.c (this should at some point be replaces by a per-gdbarch > > "ptrdiff_t" type). It also makes the subsequent patches to remove > > current_gdbarch references from value_binop simpler. > > I've got to say I don't like the direction of this change :-( > > Smarts in the expression parser are not available to reuse by other > code that constructs values - which is something I think we should be > doing more often. Why should the caller have to know that the two > values are pointers? Lets put the question differently: Why should the generic "add" routine of a debugger supporting many languages have hard-coded semantics that are specific to C (and in fact, the C ABI on a specific platform)? I was trying to make the "value_*" routines be as much as possible language- and architecture-independent, and push language- and architecture-specific semantics up to higher layers. (In this case, the expression evaluator. In fact, I might like it even better if expressions themselves were also language-agnostic, and all the language-specific semantics were encoded explicitly into different operand codes by the parsers ...) As to your question: when replacing uses of value_add, every caller *knew* whether the arguments were pointers or scalars (exept for the generic expression evaluator, of course). GDB-internal uses do not really assume the C-specific overloading of the "+" operator ... > > @@ -1531,8 +1556,19 @@ evaluate_subexp_standard (struct type *e > > goto nosideret; > > if (binop_user_defined_p (op, arg1, arg2)) > > return value_x_binop (arg1, arg2, op, OP_NULL, noside); > > + else if (ptrmath_type_p (value_type (arg1)) > > + && ptrmath_type_p (value_type (arg2))) > > + { > > + /* FIXME -- should be ptrdiff_t */ > > + type = builtin_type (exp->gdbarch)->builtin_long; > > + return value_from_longest (type, value_ptrdiff (arg1, arg2)); > > + } > > + else if (ptrmath_type_p (value_type (arg1))) > > + return value_ptrsub (arg1, arg2); > > + else if (ptrmath_type_p (value_type (arg2))) > > + return value_ptrsub (arg2, arg1); > > else > > - return value_sub (arg1, arg2); > > + return value_binop (arg1, arg2, BINOP_SUB); > > > > case BINOP_EXP: > > case BINOP_MUL: > > There's something wrong in the last else if; arg1 - arg2 != arg2 - arg1. Oops. That last case "integer - pointer" is not allowed in C anyway; this should throw an error (the old code did as well; this is a bug introduced by my change). I'll fix that ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com