From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23191 invoked by alias); 8 Jan 2018 15:00:46 -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 23093 invoked by uid 89); 8 Jan 2018 15:00:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 08 Jan 2018 15:00:25 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 83AE0A24FF; Mon, 8 Jan 2018 15:00:21 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 975E11916C; Mon, 8 Jan 2018 15:00:20 +0000 (UTC) Subject: Re: Fix gdb.ada/bp_c_mixed_case.exp (PR gdb/22670) (Re: [PATCH 3/3] Add new gdb.ada/bp_c_mixed_case testcase for PR gdb/22670) To: Joel Brobecker References: <1515054953-81012-1-git-send-email-brobecker@adacore.com> <1515054953-81012-4-git-send-email-brobecker@adacore.com> <20180108035724.gac5u77znunzhho3@adacore.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Mon, 08 Jan 2018 15:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180108035724.gac5u77znunzhho3@adacore.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-01/txt/msg00162.txt.bz2 On 01/08/2018 03:57 AM, Joel Brobecker wrote: > On Fri, Jan 05, 2018 at 04:34:39PM +0000, Pedro Alves wrote: >> Below's a fix for this one. > > Thanks! > > I confirm the test now passes for me as well :). Great! > I have a question though: > >> >From 439f8c51ff8f6cd9fb3bbc330a40492a15992add Mon Sep 17 00:00:00 2001 >> From: Pedro Alves >> Date: Fri, 5 Jan 2018 00:17:19 +0000 >> Subject: [PATCH 1/2] Fix gdb.ada/bp_c_mixed_case.exp (PR gdb/22670) >> >> The problem here is that we were using the user-provided lookup name >> literally for linkage name comparisons. I.e., "" with the >> "<>"s included. That obviously can't work since the "<>" are not >> really part of the linkage name. The original idea was that we'd use >> the symbol's language to select the right symbol name matching >> algorithm, but that doesn't work for Ada because it's not really >> possible to unambiguously tell from the linkage name alone whether >> we're dealing with Ada symbols, so Ada minsyms end up with no language >> set, or sometimes C++ set. So fix this by treating Ada mode specially >> when determining the linkage name to match against. > > I am wondering why minimal symbols are involved in this case, > considering that the C file was build with debugging information. > Shouldn't we be getting the function's address from the partial/full > symtabs instead? AFAIK, GDB always worked this way for linespecs, even before my C++ wildmatching patches -- we collect symbols from both debug info and minsyms, and coalesce them by address to avoid duplicates (linespec.c:add_matching_symbols_to_info). The completion paths then try to do the same thing (though implemented differently) [1]. I think it makes sense because: - even if you have debug information in the binary, the debug information won't cover all function symbols. Some may be internal linker-/compiler- generated symbols. Or.. - ..there may be multiple symbols with the same name in different compilation units that all end up in the same binary/objfile. Some may have debug info while others not. E.g. (C, but applies to any language, or mixed languages): static void function () {} // in file1.c, compiled with -g static int function (int p) { return p; } // in file2.c, compiled WITHOUT -g I could easily see the 'with'/'without -g' functions ending up both in the same objfile via static linking, for example. We want "b " to set a breakpoint on all the functions. [1] - the C++ wildmatching series eliminated the divergence a bit, but there's still a lot more duplication that there should ideally be. One of the points of the gdb.linespec/cpcompletion.exp and gdb.linespec/cpls-*.exp testcases is making sure that completion and actually setting a breakpoint finds the same locations. Let me know if this answers your question. Thanks, Pedro Alves