This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
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)
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 <palves@redhat.com>
>> 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., "<MixedCase>" 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 <function>" 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