This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [drow-cplus-branch rfa] using directives support
On Tue, Oct 22, 2002 at 01:18:34PM -0700, David Carlton wrote:
> and where we're at a breakpoint inside of B::foo(), if we can get a
> lookup of A::x to fail (and one of ::A::x to succeed), then that will
> be pretty impressive. I'm not exactly looking forward to reworking
> symbol lookup stuff to use iterators, either, or to getting Koenig
> lookup to work.
I think we can get it to happen. Eventually, at least. We're not
quite close enough yet...
> >> +static void
> >> +scan_for_anonymous_namespaces (struct symbol *symbol)
> >> +{
> >> + const char *name = SYMBOL_CPLUS_DEMANGLED_NAME (symbol);
> >> + const char *beginning, *end;
> >> +
> >> + /* FIXME: carlton/2002-10-14: Should we do some sort of fast search
> >> + first to see if the substring "(anonymous namespace)" occurs in
> >> + name at all? */
>
> > Definitely! This is a hideously expensive search here...
>
> Yah. What's the right way to do this? regex? There doesn't seem to
> be anything appropriate in the C standard library.
Well, there's strstr(). I don't know if it's portable, offhand,
though. Better than regex would be a loop of strchr searches for '('
and strcmps, though, I think.
> > Gives us this gem:
> > 00000000 W C<&operator+(B const &, B const &)>::member(void)
>
> Gosh. Charming. Or something. I think I'll wait until somebody
> submits a bug report complaining about that one.
Isn't that gross? I'm going to save this message and someday I'll put
it in the testsuite...
> > Not sure if this presents a problem; the parentheses in an operator
> > name will be matched, and you can't define an operator->, can you?
>
> Of course you can: this is C++, a language that allows you to redefine
> &&, ||, and the comma operator. In fact, you define it all the time
> when doing smart pointers. (And I just learned yesterday that
> operator-> has its own peculiar semantics; see chapter 7 of
> Alexandrescu's _Modern C++ Design_. But that's really not something
> I'm worried about at all right now.)
Excuse me; I was thinking of '.*'. Which of course can not be
overridden.
> >> +/* FIXME: carlton/2002-10-09: Do all the functions here handle all the
> >> + above considerations correctly? */
>
> > Almost certainly not; I hadn't thought about the (anonymous namespace)
> > thing. It may be misdetected as the arg list; if it isn't, it's blind
> > luck.
>
> I skimmed it, and actually I think you were lucky: basically, you're
> okay since (anonymous namespace) can never occur after the arg list,
> just before it (or in the middle of it), and you search from the back
> instead of the front.
Whew!
> >> +/* Let's optimize away calls to strlen("operator"). */
> >> +
> >> +#define LENGTH_OF_OPERATOR 8
>
> > A recent GCC will do this for you, actually. If glibc doesn't get in
> > its way, at least.
>
> Hmm. I don't think I want to put those strlen()s any place where they
> could be called more than once, but I could consider doing
>
> static const int length_of_operator = strlen("operator");
>
> instead. That wouldn't have much of a performance penalty on other
> compilers.
It's fine the way it is, I think.
> >> +/* FIXME: carlton/2002-10-07: That anonymous namespace example isn't
> >> + that great, since it really depends not only on what the
> >> + demangler's output is but also on the fact that the demangler's
> >> + output doesn't depend on the name of the file in question. Which,
> >> + alas, it doesn't, but should, leaving us with no way to distinguish
> >> + between anonymous namespaces in different files. Sigh... */
>
> > They may be responsive to fixing that...
>
> Yeah, I'll think about that. It's an easy enough hack to handle this
> correctly within GDB, but it's still a hack. There is one benefit to
> the current framework: if a user wants to explicitly refer to
> anonymous namespaces, then it would be easier for the user to just
> have to write '(anonymous namespace)::foo' instead of some more
> complicated demangled thing. But I don't know how likely that is.
But mightn't the user need to refer to more than one of the anonymous
namespaces?
> >> + /* FIXME: carlton/2002-10-10: is "is_a_field_of_this" always
> >> + non-NULL if we're in the C++ case? Maybe we should always do
> >> + this, and delete the two previous searches: this will always
> >> + search the global namespace, after all. */
>
> > I don't think it'll always be non-NULL - I think it's just set when the
> > caller cares about the answer. And why are searches in using
> > directives conditioned on this argument?
>
> Okay, then I'll change that accordingly; when we get around to merging
> it into mainline, we can revisit the issue.
Sure.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer