This is the mail archive of the
mailing list for the GDB project.
unqualified function names in linespecs in Ada... (try #2)
- From: Joel Brobecker <brobecker at adacore dot com>
- To: gdb-patches at sourceware dot org
- Date: Fri, 23 Dec 2011 14:38:10 +0400
- Subject: unqualified function names in linespecs in Ada... (try #2)
- References: <20111221140128.GK23376@adacore.com>
In reply to: http://www.sourceware.org/ml/gdb-patches/2011-12/msg00724.html
Just a quick reminder: The objective is to be able to insert breakpoints
using the unqualified name for functions. This has always been working,
and it actually still is mostly working today. But not quite:
(gdb) b "+"
Function ""+"" not defined.
The reason why it mostly works is thanks to a side-effect of calling
cp_canonicalize_string_no_typedefs. The objective of this patch is to
lift the dependency on this side effect.
The crux of the matter comes from the fact that Ada provides two lookup
policies: The first policy is the "full match" policy, where the user
enters the symbol's fully-qualified name (Eg: pck.foo for function foo
in package pck); The second one is the "wild match" policy, where
the user only enters the symbol's unqualified name (Eg: foo instead of
pck.foo). Which policy should be used depends on the named entered by
the user. I know that C++ users would probably say that the second
policy would never work with C++ code, giving too many matches to be
useful. But this is, probably by far, the policy that's used the most
when debugging Ada.
The policy selection is correctly made when searching the full symbols.
But the iteration through the partial symbols, on the other hand, is
still performed using one unique policy, which happens to the "full
match" one. We need a way for the language to tell the users of
partial symtab iterators which one should be used.
A new language method that returns a match routine has thus been
implemented. The newly-created la_symbol_name_compare method thus
becomes OBE and is also removed.
And once the fix is implemented, there is no longer a reason for
our name_matcher routines to be given the language. A followup patch
cleans that up too.
The whole series has been tested on x86_64-linux.