From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7226 invoked by alias); 6 Oct 2010 10:03:11 -0000 Received: (qmail 7215 invoked by uid 22791); 6 Oct 2010 10:03:10 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,TW_BJ X-Spam-Check-By: sourceware.org Received: from mail-iw0-f169.google.com (HELO mail-iw0-f169.google.com) (209.85.214.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 Oct 2010 10:03:05 +0000 Received: by iwn41 with SMTP id 41so2574742iwn.0 for ; Wed, 06 Oct 2010 03:03:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.38.9 with SMTP id z9mr13692944ibd.24.1286359383776; Wed, 06 Oct 2010 03:03:03 -0700 (PDT) Received: by 10.231.205.129 with HTTP; Wed, 6 Oct 2010 03:03:03 -0700 (PDT) In-Reply-To: <20101006085132.GA11910@host1.dyn.jankratochvil.net> References: <4CABB53A.8000101@vmware.com> <20101006085132.GA11910@host1.dyn.jankratochvil.net> Date: Wed, 06 Oct 2010 10:03:00 -0000 Message-ID: Subject: Re: disable objective-c stuff when theres no objective-c cu. From: Matt Rice To: Jan Kratochvil Cc: Michael Snyder , "gdb-patches@sourceware.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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: 2010-10/txt/msg00070.txt.bz2 On Wed, Oct 6, 2010 at 1:51 AM, Jan Kratochvil wrote: > On Wed, 06 Oct 2010 04:30:33 +0200, Matt Rice wrote: >> that we can lessen the impact by checking for is_objc_method, or for >> objective-c compilation units. (is_objc_method doesn't neccesarily >> affect future lookups should it call set_language_has_cu_loaded?) > > Wouldn't be enough to replace the bitmask just by? > =A0 =A0 =A0 =A0if (current_language->la_language =3D=3D language_objc) objective-c uses mixed compilation units possibly more than most other languages, e.g. objc++ can contain c++ and objc compilation units in the same file which we don't emit dwarf for yet, but there has been some recent work for = lto I was watching which looks to make this possibly fixable, so basing it off of 'current_language' means you may have to either use the explicit long form (discussed in news), or conversely it is possible that the short form would be able to both work/not work at different times when debugging currently you are able to set a breakpoint from languages regardless of the current one everywhere else in the decode_line_1 path, e.g. i can set a c++ one with the current language objective-c. and vice versa (well maybe not the decode_variable line with '(implicit this->)foo' personally I think that having break work consistently across compilation units is nice, and tried to get somewhere in the middle between working all the time every= where and working based on current language. >> here is when gcc started to emit DW_LANG_ObjC, maybe we could fall >> back to source files with the .m extension. >> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01515.html > > For current_language it works even without DW_LANG_ObjC due to: > =A0 =A0 =A0 =A0init_filename_language_table (void) > =A0 =A0 =A0 =A0 =A0 =A0 =A0add_filename_language (".m", language_objc); maybe the dwarf2read call to set_language_has_cu_loaded is redundant then since i added the call from set_language