Re: gdb.objc/objcdecode.exp test error..

[Joel Brobecker <brobecker at adacore dot com>]

Matt and I had a pretty long discussion on IRC about this, and I think
that the core of the problem is that we don't know how to handle
breakpoints on homonyms just yet. I wonder how things works with C++.
One day, I'll take the time to learn how GDB handles this language...

Anyway, one thing that makes it really really bad is the fact that

    (gdb) break create

can result in numerous breakpoints being set if create just happens
to be the name any ObjC method. And as it turns out, the NSThread
class has a method called "main"...

I really think that allowing the above shortcut is a mis-feature
that we should consider removing. We could possibly think about
introducing another syntax meaning all "create" methods in all
classes, if it really is needed by ObjC developers.

Another, more compromising approach, might be to start searching
ObjC method only when we did not find a symbol with that name.
In other words, do a pure C/C++ match first, and if nothing found,
then try objective-C.  We could conditionalize that to the current
language being objective-c, but I have the feeling that this is
contrary to the spirit of the current code.

Anyway, my short-term proposal is to start by either getting rid
of that feature, or else to reduce it's scope.

This would not help handling the case of breakpoint expressions
leading to more than one location.  For this, once we have determined
all possible matches, we need to be able to store their location in
a way that uniquely identifies them.  Otherwise, we wouldn't be
able to "re_set" each one of them when running the program, or when
a new shared-library is loaded.

This is an issue that's actually not limited to ObjC. We discussed
this earlier for Pascal and Ada.  We don't have a perfect solution,
but we think that this is going to be better than what we do now
(or maybe it's just me :-P).

URLs if this thread:
http://www.sourceware.org/ml/gdb-patches/2008-03/msg00473.html
http://www.sourceware.org/ml/gdb-patches/2008-09/msg00379.html

I would like us to make sure we don't lose the good work done
writing testcases, however, so I will review the latest version,
and hopefully we can commit them soon, even if it means KFAILing
some of the tests until we work on fixing them.

-- 
Joel