From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7729 invoked by alias); 23 Jul 2012 17:29:57 -0000 Received: (qmail 7721 invoked by uid 22791); 23 Jul 2012 17:29:56 -0000 X-SWARE-Spam-Status: No, hits=-7.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,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, 23 Jul 2012 17:29:36 +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 q6NHTYTS019627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 23 Jul 2012 13:29:34 -0400 Received: from spoyarek (vpn-236-220.phx2.redhat.com [10.3.236.220]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q6NHTW6D008246; Mon, 23 Jul 2012 13:29:33 -0400 Date: Mon, 23 Jul 2012 17:29:00 -0000 From: Siddhesh Poyarekar To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Make SIZE element for dwarf_block as size_t Message-ID: <20120723225922.30d293e7@spoyarek> In-Reply-To: <87fw8isfoo.fsf@fleche.redhat.com> References: <20120722131658.2809309e@spoyarek> <20120722135746.1e864ddc@spoyarek> <87fw8isfoo.fsf@fleche.redhat.com> 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: 2012-07/txt/msg00459.txt.bz2 On Mon, 23 Jul 2012 08:41:27 -0600, Tom wrote: > What about dwarf2_evaluate_loc_desc_full? > It has 'unsigned short size' as an argument but is called from > indirect_pieced_value: > > struct dwarf2_locexpr_baton baton; > [...] > return dwarf2_evaluate_loc_desc_full (TYPE_TARGET_TYPE (type), > frame, baton.data, baton.size, baton.per_cu, > piece->v.ptr.offset + > byte_offset); Ah yes, I missed that, thanks. I'll look through once more. > It would have been useful to me if you had written a bit about how you > wrote this patch and verified it. As it is, with no information on > that, I went grepping through the source to see if the patch was > complete. The fix was partly ripped out of the bitpos-expand patch[1] that I am working on, in am attempt to make that patch a little smaller (not that I've succeeded much at all). My current method for verification is just to ensure that there are no regressions in the testsuite and grepping through the code to try and ensure that I haven't missed anything (which I did this time). I don't have a reproducer that demonstrates any breakage due to this, but I can try to come up with one if it is necessary. Regards, Siddhesh [1] http://sourceware.org/ml/gdb-patches/2012-06/msg00851.html