Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Subject: unqualified function names in linespecs in Ada... (try #2)
Date: Fri, 23 Dec 2011 10:39:00 -0000	[thread overview]
Message-ID: <1324636693-24034-1-git-send-email-brobecker@adacore.com> (raw)
In-Reply-To: <20111221140128.GK23376@adacore.com>

Hello,

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.


  parent reply	other threads:[~2011-12-23 10:39 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-14 14:36 [RFC] allow unqualified function names in linespecs Joel Brobecker
2011-12-20 15:24 ` Tom Tromey
2011-12-21 14:08   ` Joel Brobecker
2011-12-23 10:39     ` [RFA 2/3] Ada: " Joel Brobecker
2012-01-12  3:13       ` Joel Brobecker
2012-01-19 15:40       ` Joel Brobecker
2012-01-24 19:41       ` Tom Tromey
2012-01-26  4:23         ` Joel Brobecker
2012-01-26 10:22           ` Crash regression gdb.cp/no-dmgl-verbose.exp: " Jan Kratochvil
2012-01-26 10:55             ` Jan Kratochvil
2012-01-27  5:15             ` Jan Kratochvil
2012-01-27  5:25               ` Joel Brobecker
2012-01-27 17:09                 ` [patch] Fix the 2012-01-26 regression by la_get_symbol_name_match_p [Re: Crash regression gdb.cp/no-dmgl-verbose.exp] Jan Kratochvil
2012-01-27 19:27                   ` Joel Brobecker
2012-01-27 20:33                     ` [commit] " Jan Kratochvil
2011-12-23 10:39     ` Joel Brobecker [this message]
2011-12-23 10:39     ` [commit/Ada 1/3] New function ada-lang.c:should_use_wild_match Joel Brobecker
2011-12-27  4:27       ` Checked in: " Joel Brobecker
2011-12-23 11:01     ` [RFA 3/3] Remove language param from name_matcher in struct quick_symbol_functions Joel Brobecker
2012-01-12  4:30       ` Joel Brobecker
2012-01-19 15:47       ` Joel Brobecker
2012-01-24 19:45       ` Tom Tromey
2012-01-26  4:57         ` Joel Brobecker
2012-01-24 19:17     ` [RFC] allow unqualified function names in linespecs Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1324636693-24034-1-git-send-email-brobecker@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox