From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26714 invoked by alias); 14 Oct 2009 01:59:55 -0000 Received: (qmail 26571 invoked by uid 22791); 14 Oct 2009 01:59:54 -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; Wed, 14 Oct 2009 01:59:51 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 629982BAC28; Tue, 13 Oct 2009 21:59:49 -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 9ATfCYbuHvv7; Tue, 13 Oct 2009 21:59:49 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 218DB2BABEF; Tue, 13 Oct 2009 21:59:49 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 77379F58A0; Tue, 13 Oct 2009 18:59:40 -0700 (PDT) Date: Wed, 14 Oct 2009 01:59:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: Matt Rice , gdb-patches@sourceware.org Subject: Re: gdb.objc/objcdecode.exp test error.. Message-ID: <20091014015940.GM5272@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> <20090924005319.GD5134@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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-10/txt/msg00292.txt.bz2 > I tend to think that the results should depend a bit on the current > language. I agree. > If we did this, then "break create" in C mode would only find the C > function of that name, but the ObjC code would be free to make > "break create" do whatever searching ObjC programmers deem reasonable. Just being the devil's advocate: The issue with this approach, I suspect, is that ObjC developers where used to be able to do ObjC debugging while in using the "c" language. It seems to be an excessive convenience at first sight, but I understand a bit the need for it, because I would imagine that a typical ObjC program is a mix of C and ObjC, not pure ObjC. So if you switch languages because you switch frames, sometimes "break foo" will "work" (when the current language is "objc", and sometimes it won't (when the language is c/c++, etc). The definition of "work" is currently meant to match the current ObjC developer expectation. I've already said that I think that the current feature is wrong and should be removed. But perhaps we can find a compromise where "break foo" now only matches "foo" when in C language, and extend the C language support to provide a way of specifying all foo ObjC methods. More generally speaking, I think it's OK to provide convenience access to non-C language features, but it should not be at the expense of the C language support. -- Joel