From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90646 invoked by alias); 19 Oct 2016 22:29:43 -0000 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 Received: (qmail 90628 invoked by uid 89); 19 Oct 2016 22:29:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:1032, Hx-spam-relays-external:cmgw3, Hx-spam-relays-external:10.0.90.84, H*RU:10.0.90.84 X-HELO: gproxy9-pub.mail.unifiedlayer.com Received: from gproxy9-pub.mail.unifiedlayer.com (HELO gproxy9-pub.mail.unifiedlayer.com) (69.89.20.122) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with SMTP; Wed, 19 Oct 2016 22:29:32 +0000 Received: (qmail 32542 invoked by uid 0); 19 Oct 2016 22:29:30 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy9.mail.unifiedlayer.com with SMTP; 19 Oct 2016 22:29:30 -0000 Received: from box522.bluehost.com ([74.220.219.122]) by cmgw3 with id xaVT1t0092f2jeq01aVWcF; Wed, 19 Oct 2016 16:29:30 -0600 X-Authority-Analysis: v=2.1 cv=KLfJUj1o c=1 sm=1 tr=0 a=GsOEXm/OWkKvwdLVJsfwcA==:117 a=GsOEXm/OWkKvwdLVJsfwcA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=CH0kA5CcgfcA:10 a=20KFwNOVAAAA:8 a=-z4uFZ0SBX8QMwnOproA:9 a=e_O65bzb51kRm2y5VmPK:22 Received: from 75-166-122-70.hlrn.qwest.net ([75.166.122.70]:46230 helo=bapiya) by box522.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1bwzMV-0005Iv-2H; Wed, 19 Oct 2016 16:29:27 -0600 From: Tom Tromey To: Pedro Alves Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFA v2 16/17] Convert dwarf_expr_context_funcs to methods References: <1476393012-29987-1-git-send-email-tom@tromey.com> <1476393012-29987-17-git-send-email-tom@tromey.com> <94f5892b-e4d2-f903-36e2-513e37f3947b@redhat.com> <878ttmid6e.fsf@tromey.com> <4e861038-bc8a-6667-9a11-6c37e7ed4489@redhat.com> <87a8e13gbp.fsf@tromey.com> <2d69a217-00ca-a516-8b65-b3d0f0133a03@redhat.com> Date: Wed, 19 Oct 2016 22:29:00 -0000 In-Reply-To: <2d69a217-00ca-a516-8b65-b3d0f0133a03@redhat.com> (Pedro Alves's message of "Tue, 18 Oct 2016 18:38:35 +0100") Message-ID: <87vawogegr.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BWhitelist: no X-Exim-ID: 1bwzMV-0005Iv-2H X-Source-Sender: 75-166-122-70.hlrn.qwest.net (bapiya) [75.166.122.70]:46230 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTIyLmJsdWVob3N0LmNvbQ== X-SW-Source: 2016-10/txt/msg00588.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> Hmm. I guess the actual code smell is that these are internal_errors Pedro> instead of normal errors in the first place? I.e., why are these two Pedro> cases internal_errors when the rest of the virtual methods have Pedro> defaults that call normal error instead? Pedro> Put another way, is there something in the inheritance design that Pedro> makes calling these default implementations a gdb bug? Pedro> So I'm wondering whether invalid dwarf (i.e., input) or something Pedro> like that could trigger these internal errors? I looked at this more concretely today by changing the internal_error-calling methods to be pure virtual, then rebuilding. This showed that the only missing overrides were in dwarf2-frame, where I think both push_dwarf_reg_entry_value and get_object_address don't make sense. So, I'll send a follow-up patch that implements these using error and uses pure virtuals. Tom