From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77148 invoked by alias); 10 Mar 2015 15:26:05 -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 77129 invoked by uid 89); 10 Mar 2015 15:26:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 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, 10 Mar 2015 15:26:04 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2AFPxbj031564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 10 Mar 2015 11:26:00 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2AFPvrB011667; Tue, 10 Mar 2015 11:25:59 -0400 Message-ID: <54FF0D05.70907@redhat.com> Date: Tue, 10 Mar 2015 15:26:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Pierre-Marie de Rodat , GDB Patches Subject: Re: [PATCH] Add proper handling for non-local references in nested subprograms References: <54F47563.4050103@adacore.com> In-Reply-To: <54F47563.4050103@adacore.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-03/txt/msg00247.txt.bz2 Hi Pierre-Marie, I would have helped this reader to include an example of "non-local references in nested subprograms" in the mail body :-) Given the reference to "subprograms" in the subject, I assumed this was an Ada-specific patch. I happened to skim the patch anyway, until I saw at the end that this also handles C nested functions. Nice! :-) On 03/02/2015 02:36 PM, Pierre-Marie de Rodat wrote: > GDB's current behavior when dealing with non-local references in the > context of nested subprograms is approximative: > > - code using valops.c:value_of_variable read the first available stack > frame that holds the corresponding variable (whereas there can be > multiple candidates for this); > > - code directly relying on read_var_value will instead read non-local > variables in frames where they are not even defined. > > This change adds necessary information to symbols (the block they belong > to) and to blocks (the static link property, if any) so that GDB can > make the proper decisions when dealing with non-local variables. > > Regtested on x86_64-linux with both GCC 4.9.2 and a patched GCC (see > ). > > PS: I'm aware that this patches increases the size of two critical data > structures (namely struct block and struct symbol) and I'm completely > open to suggestions. :-) Right, that's a problem. We've been moving in the opposite direction... The block knows which symbols it has inside. When we look up symbols, we always know which block we're searching the symbols in... If you need to know which block a symbol look up found a symbol in, there's the "block_found" for that. That's obviously an ugly hack, but it's there and so you can use it. If someone is motivated to clean this up, it'd be better to make the symbol lookup functions return a structure that included both symbol and block (and maybe more), in the spirit of struct bound_minimal_symbol: /* Several lookup functions return both a minimal symbol and the objfile in which it is found. This structure is used in these cases. */ struct bound_minimal_symbol { /* The minimal symbol that was found, or NULL if no minimal symbol was found. */ struct minimal_symbol *minsym; /* If MINSYM is not NULL, then this is the objfile in which the symbol is defined. */ struct objfile *objfile; }; For the block->static_link case, maybe put the static link chain in a separate hash indexed by block? > > Since I'm not sure of how this issue should be solved, I'm > nevertheless posting this patch here so this matter can be discussed. In > the context of this feature, I think we need a backlink from all symbols > to the corresponding embedding block but on the other hand only a few > blocks have static link: maybe we could turn this static_link field into > a objfile-based hashtable lookup. Thoughts? Ah, yeah, something like that. :-) Thanks, Pedro Alves