From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) by sourceware.org (Postfix) with ESMTPS id AAAF73858D28 for ; Mon, 18 Jul 2022 16:56:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AAAF73858D28 Received: by mail-io1-xd2f.google.com with SMTP id z132so9785801iof.0 for ; Mon, 18 Jul 2022 09:56:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=GJlF1x3BBr47C0gh9DjItC0qKXeDr7ArQcDOMc67+CA=; b=0Coi/PcaqkW+wHDdu+XZuMv4HDzhTjpxqQkV/teIaBMafKqTTp1afgh8uXbCDkh31k TsYJUoK/4yX+LrJGNEEL5fBavW70l2CW7/VZ6Xgmbq3j/FMBOtll4c24dD0h+GgJp9II l32okv0//Vpu+9Rx0VY7tzOgkPVi1vOvMF5x85yDohiRZJExASjY7F3lShGH8UA5X0+6 pbL+WyEpPbt2VgcloqsxDfdDoUkaGjGEdYg53XDHZSmDj3woiU4mdVmTamOSCe5wryYB 9Pn5IyR81rjwwyfAN8182la48Q0+/JF/28yV3TVoXg+jj+IMXX7125baDoDcBPkgHBcs MHcQ== X-Gm-Message-State: AJIora/RADCGa8ZILWw/7KuqFM7Ztpl1LIlk8J0UvGzzBz1mgFa7hLBU X87ggP6pNE+AhkcnILqhPf5mVw== X-Google-Smtp-Source: AGRyM1voqbPFh4lYhflh158Ht4Y+7sVQuD8WzyRBNRFw1FnWwfmICaB9Dvsv1Zd6ItYQvEc7XCJflw== X-Received: by 2002:a02:a88d:0:b0:33f:15e5:7fdc with SMTP id l13-20020a02a88d000000b0033f15e57fdcmr15486396jam.271.1658163412916; Mon, 18 Jul 2022 09:56:52 -0700 (PDT) Received: from murgatroyd (71-211-185-228.hlrn.qwest.net. [71.211.185.228]) by smtp.gmail.com with ESMTPSA id q28-20020a05663810dc00b00339bae1dab9sm5582875jad.40.2022.07.18.09.56.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Jul 2022 09:56:51 -0700 (PDT) From: Tom Tromey To: Markus Metzger via Gdb-patches Subject: Re: [PATCH v5 10/15] gdb, ada: update ada_add_all_symbols References: <20220602132514.957983-1-markus.t.metzger@intel.com> <20220602132514.957983-11-markus.t.metzger@intel.com> X-Attribution: Tom Date: Mon, 18 Jul 2022 10:56:50 -0600 In-Reply-To: <20220602132514.957983-11-markus.t.metzger@intel.com> (Markus Metzger via Gdb-patches's message of "Thu, 2 Jun 2022 15:25:09 +0200") Message-ID: <87fsiyl5pp.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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: Mon, 18 Jul 2022 16:56:55 -0000 >>>>> "Markus" == Markus Metzger via Gdb-patches writes: Markus> Iterate over objfile in search order using the objfile of the context Markus> block as current_objfile so the iteration can stay inside the block's Markus> linker namespace. I think this function is used by linespec, meaning it's called when setting a breakpoint. So in this case, limiting the results to the current namespace seems possibly incorrect to me. Was there a particular reason for this limitation? I tend to doubt that Ada users are using dlmopen. So maybe either way is ok. However, erring on the side of too many results seems possibly better, just in case someone does start using this combination of features. Tom