From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97641 invoked by alias); 31 Jul 2019 19:21:53 -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 97545 invoked by uid 89); 31 Jul 2019 19:21:53 -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= 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; Wed, 31 Jul 2019 19:21:52 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 62EA3116E08; Wed, 31 Jul 2019 15:21:49 -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 NOxE8qYGBcll; Wed, 31 Jul 2019 15:21:49 -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 DE4C6116C3E; Wed, 31 Jul 2019 15:21:48 -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> <877e7zky9c.fsf@tromey.com> Date: Wed, 31 Jul 2019 19:21:00 -0000 In-Reply-To: <877e7zky9c.fsf@tromey.com> (Tom Tromey's message of "Tue, 30 Jul 2019 15:28:47 -0600") Message-ID: <87a7cuhuwj.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/msg00679.txt.bz2 Tom> Digging a bit deeper, the culprit seems to be lookup_global_symbol. Tom> I think this function should respect a block that's passed in. I managed to get the new test completely passing. I changed basic_lookup_symbol_nonlocal to search the block's global block, and I removed the long comments fro 2002-3 about why this isn't done. TBH I think all of that was just mistaken. This change got to just 2 failures. The last two were both the "hidden0...main0" variants, which print: get_version_1: &this_version_id=0x7ffff7fca010, this_version_id=104 get_version_2: &this_version_id=0x7ffff7fca010, this_version_id=104 So, I think for these the answer is to change the new get_symbol_address to search all objfiles in order. I'm slightly unhappy with this but it seems correct enough. I'm re-testing the series and will resubmit it once that's done, assuming there aren't regressions. thanks, Tom