From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33173 invoked by alias); 24 Jul 2018 22:18:40 -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 33156 invoked by uid 89); 24 Jul 2018 22:18:39 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 spammy= X-HELO: sessmg23.ericsson.net Received: from sessmg23.ericsson.net (HELO sessmg23.ericsson.net) (193.180.251.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 24 Jul 2018 22:18:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1532470715; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HcR0eGUl4FDNLvXKpHCklx7esWy8Yog+6XCSgnfOMxM=; b=flOEFFnNL+Hryoyx1HZAsaDnWGzkPxyGbGCG2ZEUdyydEDcNB5w7N74C3ajBvsFS KPPebzLZsR4wq6ZkVFlGqiIoGujKM++B2mHDCL1Lg0GR/sQMRrLTTCvs/FU7nKao jxNnYw0VrIdrtvGvD95PO3rsA+mZKKESGznE5rG2Hco=; Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 24.B6.22015.BB5A75B5; Wed, 25 Jul 2018 00:18:35 +0200 (CEST) Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 25 Jul 2018 00:18:34 +0200 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 25 Jul 2018 00:18:34 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Yqsix3VPuWijyvebdO6lsCGsJ80JQhtkax8c0w+oVmk=; b=JAB8iGsyzXft8Wpz+XZcsKG7hrCo3ROG9R8i0eG6Y/VEITl2Adp+w9GX0geEG//p2XyxbS3o/ZJSUPuLV2vMtF/GpnlSVoylM/CuRTd8lSoCfk1s1b9ClkyYqz2gfi0QLyM5O5NJBnLQ/uLW5+c+mOm2amfBxbKZukL53lsupEM= Received: from [142.133.49.119] (192.75.88.130) by BN7PR15MB2387.namprd15.prod.outlook.com (2603:10b6:406:8c::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.21; Tue, 24 Jul 2018 22:18:30 +0000 Subject: Re: [PATCH PR gdb/16841] virtual inheritance via typedef cannot find base To: Weimin Pan , References: <1532128565-75923-1-git-send-email-weimin.pan@oracle.com> From: Simon Marchi Message-ID: <9fb7e028-44c2-1cec-32e0-b1431c95f074@ericsson.com> Date: Tue, 24 Jul 2018 22:18:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1532128565-75923-1-git-send-email-weimin.pan@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-Path: simon.marchi@ericsson.com Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=simon.marchi@ericsson.com; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00684.txt.bz2 On 2018-07-20 07:16 PM, Weimin Pan wrote: > Finding data member in virtual base class > > This patch fixes the original problem - printing member in a virtual base, > using various expressions, do not yield the same value. Simple test case > below demonstrates the problem: > > % cat t.cc > struct base { int i; }; > typedef base tbase; > struct derived: virtual tbase { void func() { } }; > int main() { derived().func(); } > % g++ -g t.cc > % gdb a.out > (gdb) break derived::func > (gdb) run > (gdb) p i > $1 = 0 > (gdb) p base::i > $2 = 0 > (gdb) p derived::base::i > $3 = 0 > (gdb) p derived::i > $4 = 4196392 > > To fix the problem, the virtual-base offset, relative to its derived class, > needs to be fetched, via baseclass_offset(), and used in calculating the > address of its data member in value_struct_elt_for_reference(). Hi Weimin, I have looked at this a little bit, but unfortunately I don't really understand what's going on (maybe somebody else does and could review it?). I understand the issue, and can see that your patch fixes it, but I don't understand how it does it. It would help if you could walk us through your code. It maybe also means that some comments would be appropriate, to explain what's going on. Thanks, Simon