From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27888 invoked by alias); 7 May 2013 04:37:11 -0000 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 Received: (qmail 27878 invoked by uid 89); 7 May 2013 04:37:10 -0000 X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.1 Received: from mail-ve0-f177.google.com (HELO mail-ve0-f177.google.com) (209.85.128.177) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 07 May 2013 04:37:10 +0000 Received: by mail-ve0-f177.google.com with SMTP id jw11so122426veb.8 for ; Mon, 06 May 2013 21:37:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=ThGN/vdPB0JvXh7LjC7hjCB6G/z5MVB4CdbzfncnD2I=; b=kvM0KSTkpjxeuZZ9rpPdZubHA6anD+7LCp8rbF5x3zC0qpbPVEZTX9Y+eNO00zwIb9 Zq+WbcsbG/soll+Do98Ykf7sPVUjLgIerx9/Ut1l03i9+WK33XWHq2pEYxAaP+ysEtgi KyOSucUXdhloyON+nK3MNoTqP+aJNbPBBYAYxc2mA/loZrU+hT7XeA7GTbcuT9OIZhoS Y/Cixf8Ymnv5yZErruMEo0/vCnV8PCfBAC4F8rgi5IG1bkxsQ8gYYCuxqp8kfj6Ijod9 OQ8IlWWenoa+E5pf/o+gJQyPXBsUBny1L43td7bVY1fAO12t1pusq4XlLirhhCHcI1S4 Li+w== MIME-Version: 1.0 X-Received: by 10.220.52.201 with SMTP id j9mr192606vcg.33.1367901428374; Mon, 06 May 2013 21:37:08 -0700 (PDT) Received: by 10.220.173.7 with HTTP; Mon, 6 May 2013 21:37:08 -0700 (PDT) In-Reply-To: <20130507014724.GA14170@host2.jankratochvil.net> References: <20130501165750.GA453@host2.jankratochvil.net> <87obcoyot3.fsf@fleche.redhat.com> <20130506181832.GA23882@host2.jankratochvil.net> <878v3symbc.fsf@fleche.redhat.com> <20130507014724.GA14170@host2.jankratochvil.net> Date: Tue, 07 May 2013 04:37:00 -0000 Message-ID: Subject: Re: [patch 2/2] Assert leftover cleanups in TRY_CATCH From: Doug Evans To: Jan Kratochvil Cc: Tom Tromey , gdb-patches Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnY6S19mZzUJm3QqjhSavIokHZDZtDsgupf+xQOJnxNWlWG1FTmec7tAU0KXNyYlOZiOFnyXyXkz4z9ldi/1Ds+CwEExQfMchkxOVE11lFan/mjwJXkUz8J+tUTmAXzh2wKj4ZlW4tAdwhmDz5aoP6uhtvi7tdL3aOGcuOSKpN6mhLS4yObCNctwUPIrLxw+yh6+8tlWUPOpj/ouHDPXYSAoDnioQ== X-SW-Source: 2013-05/txt/msg00171.txt.bz2 On Mon, May 6, 2013 at 6:47 PM, Jan Kratochvil wrote: > On Mon, 06 May 2013 20:50:47 +0200, Tom Tromey wrote: >> >>>>> "Jan" == Jan Kratochvil writes: >> Jan> C++ exceptions solve it all, everyone knows it, it is simple, >> Jan> effective and at least in comparison with the existing GDB system >> Jan> it is foolproof. >> >> I know, and I agree that it would yield a better gdb, but I don't think >> it is going to happen. > > I can't seriously reply these questions anymore. GCC already requires C++ so > why GDB cannot? I do not remember any valid reason against C++ from all the > GDB discussions around it. > > GDB still is barely usable for real C++ application debugging, debugging > multiple virtual class inheritance does not work, one has to use printfs > instead. Inferior breakpoint with conditional to stop only after thousands of > iterations is so unusably slow it is faster to rebuild the inferior with the > conditional put into inferior's source. etc. etc. I'm not going to enter an opinion of C over C++ here, but I don't see how inferior breakpoint slowness is related. [I can imagine a reason why multiple virtual class inheritance is related, but then again I'm not sure I'd want to see gdb use it itself.] btw, is the slowness just an all-stop thing? Or is there room for massive improvement in non-stop too?