This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: gdb.objc/objcdecode.exp test error..
- From: Matt Rice <ratmice at gmail dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 24 Sep 2009 01:24:44 -0700
- Subject: Re: gdb.objc/objcdecode.exp test error..
- References: <8ba6bed40903051731s41c9183aha18af51113f3c0ea@mail.gmail.com> <20090306173345.GI3744@adacore.com> <200903061913.43419.pedro@codesourcery.com> <8ba6bed40903070407q3e91f0ffs6fc67b2b9c329081@mail.gmail.com> <8ba6bed40903080716k3fbeb56t5605aef1864b26a3@mail.gmail.com> <8ba6bed40903081910t695c9d93jc34ba1c5d2793a2e@mail.gmail.com> <8ba6bed40909110443v61597c4ci7effd224ce26f937@mail.gmail.com> <20090924005319.GD5134@adacore.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.