From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9300 invoked by alias); 21 Feb 2012 20:43:01 -0000 Received: (qmail 9286 invoked by uid 22791); 21 Feb 2012 20:42:59 -0000 X-SWARE-Spam-Status: No, hits=-7.0 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; Tue, 21 Feb 2012 20:42:25 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1LKgP76012250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 21 Feb 2012 15:42:25 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q1LKgObT010191; Tue, 21 Feb 2012 15:42:24 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id q1LKgNKn008291; Tue, 21 Feb 2012 15:42:23 -0500 From: Tom Tromey To: Siddhesh Poyarekar Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Expand bitpos to LONGEST to allow access to large offsets within a struct References: <20120220132724.GB4753@spoyarek.pnq.redhat.com> Date: Tue, 21 Feb 2012 20:46:00 -0000 In-Reply-To: <20120220132724.GB4753@spoyarek.pnq.redhat.com> (Siddhesh Poyarekar's message of "Mon, 20 Feb 2012 18:58:24 +0530") Message-ID: <87d397syts.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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-02/txt/msg00451.txt.bz2 >>>>> "Siddhesh" == Siddhesh Poyarekar writes: Siddhesh> If a struct member is at an offset greater than or equal to Siddhesh> 0x10000000, the resulting bit position within the struct Siddhesh> overflows and causes an invalid access. The following program Siddhesh> demonstrates this problem: Thanks for doing this. It is a long-needed fix. Siddhesh> This happens because the bitpos in field_location within the struct Siddhesh> main_type.field is declared as an int, limiting it to just 4 bytes. I Siddhesh> have attached a patch that expands this to LONGEST and adjusted this Siddhesh> change in the code. The testsuite does not report any regressions due Siddhesh> to this patch and it fixes the problem. I think this should fix http://sourceware.org/bugzilla/show_bug.cgi?id=7259. If so, at the top of the ChangeLog, write 'PR symtab/7259:'. If it does fix this PR then this suggests a simple test case that doesn't require a huge allocation. Most of the patch seems perfectly fine -- just the logical consequence of the core change. However there are a few issues, mostly minor. Siddhesh> printfi_filtered (spaces + 2, Siddhesh> - "[%d] bitpos %d bitsize %d type ", Siddhesh> + "[%d] bitpos %ld bitsize %d type ", Siddhesh> idx, TYPE_FIELD_BITPOS (type, idx), You can't really rely on the size of LONGEST. Instead you have to use %s and 'plongest'. There are a few instances of this in the patch. Siddhesh> diff --git a/gdb/value.c b/gdb/value.c Siddhesh> index 583be33..49a6f43 100644 Siddhesh> --- a/gdb/value.c Siddhesh> +++ b/gdb/value.c Siddhesh> @@ -308,7 +308,7 @@ struct value Siddhesh> `type', and `embedded_offset' is zero, so everything works Siddhesh> normally. */ Siddhesh> struct type *enclosing_type; Siddhesh> - int embedded_offset; Siddhesh> + LONGEST embedded_offset; Siddhesh> int pointed_to_offset; I think you also have to widen the 'offset' field, and probably also 'pointed_to_offset'. This will probably have other consequences, e.g., value_offset will have a different return type. Tom