From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7406 invoked by alias); 1 Jul 2014 18:25:03 -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 6989 invoked by uid 89); 1 Jul 2014 18:24:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 01 Jul 2014 18:24:58 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s61IOuai024063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 1 Jul 2014 14:24:56 -0400 Received: from barimba (ovpn-113-95.phx2.redhat.com [10.3.113.95]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s61IOtZk027227 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Tue, 1 Jul 2014 14:24:56 -0400 From: Tom Tromey To: Mark Wielaard Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Handle volatile array types in dwarf2read.c. References: <1404164071-24432-1-git-send-email-mjw@redhat.com> <87simlrroa.fsf@fleche.redhat.com> <1404238306.3766.17.camel@bordewijk.wildebeest.org> Date: Tue, 01 Jul 2014 18:25:00 -0000 In-Reply-To: <1404238306.3766.17.camel@bordewijk.wildebeest.org> (Mark Wielaard's message of "Tue, 01 Jul 2014 20:11:45 +0200") Message-ID: <87ionhq6mg.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2014-07/txt/msg00024.txt.bz2 Mark> But we have to look anyway. This is just the existing code, moved into Mark> its own function. What do you suggest should be changed? It's fine to leave it. Tom> make_cv_type preserves the already existing qualifiers so you don't need Tom> to track "cnst" and "voltl". You can just pass in the ones you want to Tom> add. Mark> The original code already did it this way. And I don't think it is true Mark> that make_cv_type preserves existing const or volatile qualifiers. Wow, I wonder how long I've had the incorrect view of make_cv_type. Hopefully not too long. Thanks for pointing that out. Tom> I wonder about typedefs to array type. Tom> Calling check_typedef here is probably not so great but I assume we can Tom> just ignore incomplete types. Mark> I am not sure I understand precisely what you are wondering about. Do Mark> you have an example? Then I can add a testcase for it. This is just Mark> precisely as is done for the const case. So the issue you are thinking Mark> about is probably the same for both cases and might already be existing. Well, I was thinking this: typedef int atype[23]; const atype a; However, gcc omits the typedef from the DWARF, so I suppose some hand-crafted DWARF would have to be written. This patch is ok. If there's a further bug and you want to fix it, it's fine to do that separately. Tom