From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21602 invoked by alias); 5 Mar 2012 06:34:43 -0000 Received: (qmail 21313 invoked by uid 22791); 5 Mar 2012 06:34:42 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 05 Mar 2012 06:34:26 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q256YQ4d005534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 5 Mar 2012 01:34:26 -0500 Received: from spoyarek.pnq.redhat.com (dhcp233-8.pnq.redhat.com [10.65.223.8] (may be forged)) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q256YLFf028838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 5 Mar 2012 01:34:24 -0500 Date: Mon, 05 Mar 2012 06:34:00 -0000 From: Siddhesh Poyarekar To: Jan Kratochvil Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH] Expand bitpos to LONGEST to allow access to large offsets within a struct Message-ID: <20120305063542.GA30196@spoyarek.pnq.redhat.com> References: <20120220132724.GB4753@spoyarek.pnq.redhat.com> <87d397syts.fsf@fleche.redhat.com> <20120229135148.GA32128@spoyarek.pnq.redhat.com> <20120301224428.GA30631@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120301224428.GA30631@host2.jankratochvil.net> User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2012-03/txt/msg00131.txt.bz2 On Thu, Mar 01, 2012 at 11:44:28PM +0100, Jan Kratochvil wrote: > But to make this patch really working for struct offsets (and not just enum's) > one needs to also extend the type->length width. I am sorry but it will be > a big patch. OK, will work on this. > splint gives nice advices, thanks for the idea. I think it would not give a > warning if there is incorrectly used 'long' instead of LONGEST'. I think it should give this warning on ia32, since there is a storage size mismatch there. That said, I need to test on 32-bit the next time too. > > - ((TYPE_UNSIGNED (type) ? ax_zero_ext : ax_ext) (ax, end - start)); > > + ((TYPE_UNSIGNED (type) ? ax_zero_ext : ax_ext) (ax, (int)(end - start))); > > Here I think ax_zero_ext and ax_ext should use LONGEST instead of the cast. > (OK, one may argue a bit about it.) > The reason I cast it down to INT is because the eventual call to generic_ext() requires N to be between 0 and 255. But I guess we might want to keep the value intact to catch any internal bugs that may trigger this? Thanks for your very detailed review. I'll fix up the patch and also expand type->length. -- Siddhesh