From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31836 invoked by alias); 7 Oct 2019 14:58: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 31828 invoked by uid 89); 7 Oct 2019 14:58:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=UD:ca, polymtl.ca, polymtlca, UD:polymtl.ca X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 07 Oct 2019 14:58:41 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id x97EwTVt024324 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 7 Oct 2019 10:58:34 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca x97EwTVt024324 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1570460315; bh=lHhR+MFV3sbmtIZ782MU9jB4sCd4Sf7lxQkte+UpQj4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=tTyEd0Pp6usRKJSDy25GOhhhowzPHZMeOescjf8AVNPAZYM1m08/vuaGQn2Qk1svx n1Aniuu/4DzqLLe0ZzgGIQrR/M2thd63pFZ9VPSyGyge+jM4w74EcwudeaRTudjOb0 naNx4rjM5FFiXgT2j896lVFX7ofM4X0hNx6dIO4U= Received: from [172.16.0.148] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 8D70E1E0A4; Mon, 7 Oct 2019 10:58:28 -0400 (EDT) Subject: Re: [PATCH v3] gdb: CTF support To: Andrew Burgess , Tom de Vries Cc: Weimin Pan , gdb-patches@sourceware.org References: <1570143372-27092-1-git-send-email-weimin.pan@oracle.com> <596e6b5b-901b-b1ad-fb9a-3a6631f44547@suse.de> <20191007120723.GO4962@embecosm.com> From: Simon Marchi Message-ID: <89a5ee6d-e9c7-5b6f-22b8-edb3ec50f369@polymtl.ca> Date: Mon, 07 Oct 2019 14:58:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20191007120723.GO4962@embecosm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg00189.txt.bz2 On 2019-10-07 8:07 a.m., Andrew Burgess wrote: > * Tom de Vries [2019-10-07 11:33:12 +0200]: > >> On 04-10-19 00:56, Weimin Pan wrote: >>> +/* The routines that read and process fields/members of a C struct, union, >>> + or enumeration, pass lists of data member fields in an instance of a >>> + field_info structure. It is derived from dwarf2read.c. */ >>> + >>> +struct nextfield >>> +{ >>> + struct field field {}; >>> +}; >>> + >>> +struct field_info >> >> Hi, >> >> not only is field_info derived from dwarf2read.c, it uses the same name >> for the type. This is a C++ One-Definition-Rule violation, which causes >> most of the test-suite to start failing for me. >> >> What happens is that here: >> ... >> if (die->child != NULL && ! die_is_declaration (die, cu)) >> { >> struct field_info fi; >> std::vector template_args; >> ... >> the constructor for field_info is called, but it calls the constructor >> for field_info defined in ctfread.c rather than dwarf2read.c. > > Tom, > > Thanks for tracking this down. I had just run into the same issue. > I've pushed the patch below which I believe fixes this issue. > > Weimin, > > Hopefully you're happy with this fix, I guess if you'd rather see an > alternative solution then feel free to propose one. > > Thanks, > Andrew > > --- > > From b2caee6aaa78106d7ae3c46dda3a84a325e43a1d Mon Sep 17 00:00:00 2001 > From: Andrew Burgess > Date: Mon, 7 Oct 2019 12:34:51 +0100 > Subject: [PATCH] gdb: Rename structures within ctfread.c > > Commit: > > commit 30d1f0184953478d14641c495261afd06ebfabac > Date: Mon Oct 7 00:46:52 2019 +0000 > > gdb: CTF support > > Introduces some structures with names that are already in use within > GBB, this violates C++'s one-definition rule. Specifically the > structures 'nextfield' and 'field_info' are now defined in > dwarf2read.c and ctfread.c. > > This commit renames the new structures (in ctfread.c), adding a 'ctf_' > prefix. Maybe we should consider renaming the DWARF versions too in > the future to avoid accidental conflicts. Thanks guys for catching this. Just in case you didn't already know, another way to avoid these problems (if we apply it everywhere) is to define everything that is local to a source file in an anonymous namespace. I don't really have the habit of doing it at the moment, but maybe I should start to do it consistently. Simon