From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16234 invoked by alias); 25 Mar 2014 16:51:57 -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 16216 invoked by uid 89); 25 Mar 2014 16:51:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: forward-corp1g.mail.yandex.net Received: from forward-corp1g.mail.yandex.net (HELO forward-corp1g.mail.yandex.net) (95.108.253.251) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 25 Mar 2014 16:51:54 +0000 Received: from smtpcorp4.mail.yandex.net (smtpcorp4.mail.yandex.net [95.108.252.2]) by forward-corp1g.mail.yandex.net (Yandex) with ESMTP id 547AB366099F for ; Tue, 25 Mar 2014 20:51:50 +0400 (MSK) Received: from smtpcorp4.mail.yandex.net (localhost [127.0.0.1]) by smtpcorp4.mail.yandex.net (Yandex) with ESMTP id 11A482C085A for ; Tue, 25 Mar 2014 20:51:50 +0400 (MSK) Received: from unknown (unknown [2a02:6b8:0:408:925:eeb7:fff:3c60]) by smtpcorp4.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id tkzU36SrIm-pndmmca0; Tue, 25 Mar 2014 20:51:50 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: d14041b1-5e32-4126-aaea-4e743c494937 Authentication-Results: smtpcorp4.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH 0/3] Fixed abortion using Python API for label symbol object. From: Maxim Bublis In-Reply-To: <1393929360-31299-1-git-send-email-satori@yandex-team.ru> Date: Tue, 25 Mar 2014 16:51:00 -0000 Content-Transfer-Encoding: quoted-printable Message-Id: <4369C88E-D0A5-4F4F-8937-5ABDBABD8BC9@yandex-team.ru> References: <1393929360-31299-1-git-send-email-satori@yandex-team.ru> To: gdb-patches@sourceware.org X-SW-Source: 2014-03/txt/msg00597.txt.bz2 Hi, Is there any way to notify gdb.python maintainer to review this patch set? =97 Maxim Bublis >From gdb-patches-return-111400-listarch-gdb-patches=sources.redhat.com@sourceware.org Tue Mar 25 17:51:00 2014 Return-Path: Delivered-To: listarch-gdb-patches@sources.redhat.com Received: (qmail 28994 invoked by alias); 25 Mar 2014 17:50:59 -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 Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 28984 invoked by uid 89); 25 Mar 2014 17:50:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 25 Mar 2014 17:50:57 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id E1F331167C2; Tue, 25 Mar 2014 13:50:55 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3099Cvgm6ZRa; Tue, 25 Mar 2014 13:50:55 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id B8E2C11669A; Tue, 25 Mar 2014 13:50:55 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 98D98E07DC; Tue, 25 Mar 2014 10:50:56 -0700 (PDT) Date: Tue, 25 Mar 2014 17:50:00 -0000 From: Joel Brobecker To: Keith Seitz Cc: "gp >> \"gdb-patches@sourceware.org ml\"" Subject: Re: [RFA] Fix c++/16253 (tag/variable name collision) Message-ID: <20140325175056.GO4282@adacore.com> References: <532C810F.7010809@redhat.com> <20140324141527.GM4282@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140324141527.GM4282@adacore.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-03/txt/msg00598.txt.bz2 Content-length: 2029 Hey Keith, > > I must also give a shout out to Joel -- I've largely avoided hacking > > with/at Ada. In fact, Ada *largely* remains unchanged. However, it > > now must explicitly search STRUCT_DOMAIN in a few places itself (an > > analogous change to the other symbol table API changes I've made). > > Joel, if you could run this through your internal AdaCore test > > harness, that would be most helpful. > > I had a chance to test your patch today, and unfortunately our testsuite > detected some regressions. I think they might all be the same, so I > picked the simplest testcase. I might be running short of time today > to look deeper into this, but I can try scheduling some time for it > tomorrow or Wed. > > % gnatmake -g foo > % gdb foo > (gdb) ptype base Insert missing "No definition of "base" in current context." as the output of the "ptype base" command above... I had a chance to investigate the source of the problem, and I think I understand it, now. Basically, I think you fixed up the Ada symbol lookups for local symbols, but did not adjust the non-local lookups. In our case, our type "base" is defined in unit foo.adb as a static (non-global) STRUCT_DOMAIN symbol. The symbol lookup is performed via ada-lang.c::add_nonlocal_symbols which calls objfile->sf->qf->map_matching_symbols (=map_matching_symbols_psymtab). And the match now fails since it performs strict domain matching. I think you actually ended up noticing the problem, since you had to change ada-tasks to do a STRUCT_DOMAIN search instead of a VAR_DOMAIN search. I think the ada-tasks change is correct regardless, since these are all structure types anyways (need to double-check, but pretty sure), but that was also a clue. Now, the question becomes: Does Ada need to add some logic to call objfile->sf->qf->map_matching_symbols a second time with STRUCT_DOMAIN, or should objfile->sf->qf->map_matching_symbols do it? From the looks of your patch, it looks like this should be done on the Ada side? Thanks! -- Joel