Re: [PATCH 0/3] Fixed abortion using Python API for label symbol object.

[Maxim Bublis <satori@yandex-team.ru>]

Hi,

Is there any way to notify gdb.python maintainer to review this patch set?

—
Maxim Bublis
From gdb-patches-return-111400-listarch-gdb-patches=sources.redhat.com@sourceware.org Tue Mar 25 17:51:00 2014
Return-Path: <gdb-patches-return-111400-listarch-gdb-patches=sources.redhat.com@sourceware.org>
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: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
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 <brobecker@adacore.com>
To: Keith Seitz <keiths@redhat.com>
Cc: "gp >> \"gdb-patches@sourceware.org ml\"" <gdb-patches@sourceware.org>
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