From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54670 invoked by alias); 30 Jul 2019 21:28:50 -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 54663 invoked by uid 89); 30 Jul 2019 21:28:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=culprit 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 ESMTP; Tue, 30 Jul 2019 21:28:49 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 3BFA51166B1; Tue, 30 Jul 2019 17:28:48 -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 S5ysYerm2Msv; Tue, 30 Jul 2019 17:28:48 -0400 (EDT) Received: from murgatroyd (97-122-178-82.hlrn.qwest.net [97.122.178.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPSA id B88541166AE; Tue, 30 Jul 2019 17:28:47 -0400 (EDT) From: Tom Tromey To: Tom Tromey Cc: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [PATCH 2/4] Handle copy relocations References: <20190627145235.21222-1-tromey@adacore.com> <20190627145235.21222-3-tromey@adacore.com> <87d0hrkzl3.fsf@tromey.com> Date: Tue, 30 Jul 2019 21:28:00 -0000 In-Reply-To: <87d0hrkzl3.fsf@tromey.com> (Tom Tromey's message of "Tue, 30 Jul 2019 15:00:08 -0600") Message-ID: <877e7zky9c.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-07/txt/msg00668.txt.bz2 Tom> I haven't investigated the other failures yet, but I think this one in Tom> particular is an existing bug in c-exp.y. What happens is that this Tom> does not actually look up the symbol from that source file! Instead it Tom> finds the symbol in print-file-var-lib1.c. Digging a bit deeper, the culprit seems to be lookup_global_symbol. I think this function should respect a block that's passed in. However, this code also calls gdbarch_iterate_over_objfiles_in_search_order and solib_global_lookup, and now I wonder if one or both of these needs to be changed as well. For example, if stopped in the library, "print this_version_id" should probably follow the expected-by-the-library-author lookup, but currently I think will not. Maybe windows_iterate_over_objfiles_in_search_order should just be the default. I am not sure. Tom