From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20529 invoked by alias); 24 Sep 2009 00:53:34 -0000 Received: (qmail 20518 invoked by uid 22791); 24 Sep 2009 00:53:33 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 24 Sep 2009 00:53:23 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id ED6892BABE8; Wed, 23 Sep 2009 20:53:21 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NODCA1SzrfD6; Wed, 23 Sep 2009 20:53:21 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id AE0D22BAB1C; Wed, 23 Sep 2009 20:53:21 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 7D2B0F594B; Wed, 23 Sep 2009 17:53:19 -0700 (PDT) Date: Thu, 24 Sep 2009 00:53:00 -0000 From: Joel Brobecker To: Matt Rice Cc: gdb-patches@sourceware.org Subject: Re: gdb.objc/objcdecode.exp test error.. Message-ID: <20090924005319.GD5134@adacore.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8ba6bed40909110443v61597c4ci7effd224ce26f937@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00734.txt.bz2 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