From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2348 invoked by alias); 31 Jan 2005 21:33:23 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 1763 invoked from network); 31 Jan 2005 21:32:47 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 31 Jan 2005 21:32:47 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j0VLWl2a008592 for ; Mon, 31 Jan 2005 16:32:47 -0500 Received: from firetop.home (vpn50-89.rdu.redhat.com [172.16.50.89]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0VLWlO24427 for ; Mon, 31 Jan 2005 16:32:47 -0500 Received: from rsandifo by firetop.home with local (Exim 4.34) id 1CvjA6-0008BB-IA for binutils@sources.redhat.com; Mon, 31 Jan 2005 21:32:46 +0000 To: binutils@sources.redhat.com Subject: Re: Bignums and .sleb128 References: <20050131195417.GA6254@nevyn.them.org> From: Richard Sandiford Date: Mon, 31 Jan 2005 21:33:00 -0000 In-Reply-To: <20050131195417.GA6254@nevyn.them.org> (Daniel Jacobowitz's message of "Mon, 31 Jan 2005 14:54:17 -0500") Message-ID: <87brb5p9mp.fsf@firetop.home> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-01/txt/msg00569.txt.bz2 Daniel Jacobowitz writes: > I spent most of this morning chasing a bug in .sleb128 support. After > I finished running around in circles and discovered that Richard Sandiford > had fixed it two weeks ago (thanks!) I compared the testcases I'd written > with the ones that he committed. There were a couple of differences, > basically related to this comment from bignum.h: > > * Bignums are >= 0. * Ugh, didn't notice that, sorry. But I think that comment fell by the wayside the moment we tried to handle '-' for O_bigs. After all, the precision of bignums is completely arbitrary, so if the result of -bignum is supposed to be unsigned, there's no obvious cut-off point for the sign extension. You said later that: > If we're going to use these semantics, at least the '-' case in > operand() needs to be fixed. but I wasn't sure what you meant by "these semantics". Do you mean treating bignums as signed, or treating them as unsigned? By my reading, operand()'s current handling of '-' already assumes they are signed, just like the sleb128 code does (and did ;). > So generating a sleb128 from one is pretty strange - the sign bit is > ambiguously handled. Perhaps, but the problem isn't limited to sleb128. E.g.: .quad -0xffffffffffff acts in the same way as ".quad 1", not ".quad 0xffff000000000001". The direction of recent changes suggests there really is a need for negative bignums, so IMO we should try to support them. Richard