From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id E67C338582B9 for ; Sat, 16 Jul 2022 00:04:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E67C338582B9 Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-221-8Q6waSa5MIWUAd1fg19jqw-1; Fri, 15 Jul 2022 20:04:57 -0400 X-MC-Unique: 8Q6waSa5MIWUAd1fg19jqw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 098EC3C025C6; Sat, 16 Jul 2022 00:04:57 +0000 (UTC) Received: from f35-zws-1 (unknown [10.2.17.184]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BCD532026D64; Sat, 16 Jul 2022 00:04:56 +0000 (UTC) Date: Fri, 15 Jul 2022 17:04:53 -0700 From: Kevin Buettner To: "Metzger, Markus T" Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v5 00/15] basic linker namespace support Message-ID: <20220715170453.1d5142e2@f35-zws-1> In-Reply-To: References: <20220602132514.957983-1-markus.t.metzger@intel.com> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2022 00:05:00 -0000 Hi Markus, On Fri, 15 Jul 2022 10:30:42 +0000 "Metzger, Markus T" wrote: > OK'ed by Kevin: > > gdb, solib-svr4: remove locate_base() > > gdb, gdbserver: support dlmopen() > > gdbserver: move main_lm handling into caller > > gdb, gdbserver: extend RSP to support namespaces > > gdb, compile: unlink objfile stored in module > > gdb, ada: update ada_lookup_simple_minsym > > gdb, hppa: remove unused hppa_lookup_stub_minimal_symbol > > gdb, symtab: inline find_quick_global_symbol_language > > gdb, solib-svr4: support namespaces in DSO iteration Yep. > Reviewed by Kevin but asking for another reviewer: > > gdb, ada: update ada_add_all_symbols To be clear, I think this patch is okay, but someone who knows about this area may want to take a look. If no one steps up, I think it should go in. > > Not reviewed: > > gdb, testsuite: extend gdb_test_multiple checks I asked a question about this one. Basically, I'd like to understand the circumstances which led you to making these changes. > > gdb, python: use gdbarch_iterate_over_objfiles_in_search_order I okayed this one. > > gdb, ada: collect standard exceptions in all objfiles That one looked reasonable to me, but an Ada expert may want to take a look. > > gdb, cp: update add_symbol_overload_list_qualified I said, "LGTM", which is basically an "okay". > > gdb: update gnu ifunc resolve I okayed this one. > > Another question is what to do about those known issues: > > > - get_symbol_address() and get_msymbol_address() search objfiles for a > > 'better' match. This was introduced by > > > > 4b610737f02 Handle copy relocations > > > > to handle copy relocations but it now causes a wrong address to be > > read after symbol lookup actually found the correct symbol. This can > > be seen, for example, with gdb.base/dlmopen.exp when compiled with > > clang. > > > > - gnu ifuncs are only looked up in the initial namespace. > > > > - lookup_minimal_symbol() and lookup_minimal_symbol_text() directly > > iterate over objfiles and are not aware of linker namespaces. > > Can they be accepted and addressed one-by-one? Or would they all need > to be addressed before the series can be merged? I had to adjust two expected > outputs but otherwise, tests pass on x86-64. We know that namespace > support is incomplete, though. > > For get_symbol_address() and get_msymbol_address() I believe we need > to remove the objfiles iteration and trust that the symbol is the right one > and just return its value. That means we need to find another way to > handle copy relocations. I was hoping that someone could help with that. I'd like to see this work go in. So long as it doesn't break existing (non-linker namespace) use cases, I'm okay with fixing the other problems later on. Kevin