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

[Matt Rice <ratmice@gmail.com>]

On Wed, Sep 23, 2009 at 5:53 PM, Joel Brobecker <brobecker@adacore.com> wrote:
> 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...

well, I know overloaded methods are handled by encoding the type

e.g. foo(char), foo(int)
so those are canonical.

> 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.

I agree, I've sent an email to the discuss-gnustep asking for feedback...

the thread is here:
http://thread.gmane.org/gmane.comp.lib.gnustep.general/33219

> 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.

I see this little gem in objc-lang.c, so this apparently used to be
the case, not sure why it changed

 * Note that it is possible for a normal (c-style) function to have
 * the same name as an objective c selector.  To prevent the selector
 * from eclipsing the function, we allow the caller (decode_line_1) to
 * search for such a function first, and if it finds one, pass it in
 * to us.  We will then integrate it into the list.  We also search
 * for one here, among the minsyms.


>  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.

It just occured to me that we could canonicalize these homonyms
using '-[Foo() bar]' to mean method not in a category, and
'-[Foo(categoryName) bar]', that also means extending decode_objc to
accept -[Foo() bar] syntax I'm not sure if it will currently accept
it.

> 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.

I'll get working on patches for these short-term things in the morning.