From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12447 invoked by alias); 21 Feb 2002 02:05:01 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12297 invoked from network); 21 Feb 2002 02:04:59 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 21 Feb 2002 02:04:59 -0000 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16dibR-0003Fb-00; Wed, 20 Feb 2002 21:04:57 -0500 Date: Wed, 20 Feb 2002 18:05:00 -0000 From: Daniel Jacobowitz To: Per Bothner Cc: gdb-patches@sources.redhat.com Subject: Re: Fix PR gdb/265, 64-bit pointers in Java Message-ID: <20020220210457.A11990@nevyn.them.org> Mail-Followup-To: Per Bothner , gdb-patches@sources.redhat.com References: <20020211003818.A26546@nevyn.them.org> <20020220174154.A29999@nevyn.them.org> <3C742B97.2060609@bothner.com> <20020220184414.A7963@nevyn.them.org> <3C744DC0.1090902@bothner.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C744DC0.1090902@bothner.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-02/txt/msg00580.txt.bz2 On Wed, Feb 20, 2002 at 05:30:40PM -0800, Per Bothner wrote: > Daniel Jacobowitz wrote: > >Well, it does not silently change the type for conforming input; > >integers will still be marked as integers. The patch allows us to accept > >things like: > >(gdb) x/i 0x123456789 > > > >which really ought to work. > > I'm not 100% convinced, but it's at least reasonable. > > >If you disagree with me on that, which you certainly can :), then I > >would prefer to have a flag for parse_number saying it created an > >implicit long and cause errors if the expression being evaluated is a > >method call, etc. I'm not convinced that's worth the trouble. > > An idea: If it overflows, set the type to builtin_type_uint64, or some > similar type, but don't set it to java_type_long. That way we still > get x/i 0x123456789 to do the expected, but we can (if we wanted to) > catch incorrectly passing 0x123456789 to a Java method. I like it. > This is similar to how G++ treets jint (__java_int), as a different > integer type than int, so it can can programs that try to incorrectly > pass an 'int' to a Java method. > > If you change it to: > > if (type == java_int_type && n > (ULONGEST)0x80000000) > type = builtin_type_uint64; > > then that would satisfy me. This look OK? Note the comment. Index: jv-exp.y =================================================================== RCS file: /cvs/src/src/gdb/jv-exp.y,v retrieving revision 1.4 diff -u -p -r1.4 jv-exp.y --- jv-exp.y 2002/02/20 22:41:52 1.4 +++ jv-exp.y 2002/02/21 02:04:19 @@ -797,8 +797,13 @@ parse_number (p, len, parsed_float, puti n += c; } - if (type == java_int_type && n > (ULONGEST)0xffffffff) - type = java_long_type; + /* If the type is bigger than a 32-bit signed integer can be, implicitly + promote to long. Java does not do this, so mark it as builtin_type_uint64 + rather than java_long_type. 0x80000000 will become -0x80000000 instead + of 0x80000000L, because we don't know the sign at this point. + */ + if (type == java_int_type && n > (ULONGEST)0x80000000) + type = builtin_type_uint64; putithere->typed_val_int.val = n; putithere->typed_val_int.type = type; -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer