From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Cj9UMsAA0mJM1RMAWB0awg (envelope-from ) for ; Fri, 15 Jul 2022 20:05:20 -0400 Received: by simark.ca (Postfix, from userid 112) id B408A1E5EA; Fri, 15 Jul 2022 20:05:20 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=wMUBE5dk; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 518621E222 for ; Fri, 15 Jul 2022 20:05:20 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CD3103857370 for ; Sat, 16 Jul 2022 00:05:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CD3103857370 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1657929919; bh=YlZK0RUwZEczMZQahcO+gZ/GoNZNznVd9lPsV0IfwJo=; h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=wMUBE5dkAu/nls72ZhqIcV4x+gESxGKI7UkfZA9QzUFWFz4T0DLKvmbmhqDrQgWD3 30xdr8Hlqe9gWyPDPK/YNvcs9TpXobwj57y6hPo0PjyMEAOo279ep0futGD+ACP34n sl7skVWlDcVX8F5IhR20hKEeZUCzVrQcS80l17Ao= 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 To: "Metzger, Markus T" 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-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: , From: Kevin Buettner via Gdb-patches Reply-To: Kevin Buettner Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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