From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17434 invoked by alias); 18 Jan 2013 14:31:07 -0000 Received: (qmail 17415 invoked by uid 22791); 18 Jan 2013 14:31:04 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 Jan 2013 14:30:58 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r0IEUqLp000763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 18 Jan 2013 09:30:58 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r0IEUhqx022828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 18 Jan 2013 09:30:46 -0500 From: Tom Tromey To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: RFC: fix PR 12707 References: <87r4lno936.fsf@fleche.redhat.com> <20130115172149.GA21127@host2.jankratochvil.net> <87pq13biy8.fsf@fleche.redhat.com> <20130117215358.GA18048@host2.jankratochvil.net> <87librbhd6.fsf@fleche.redhat.com> <20130117220437.GA18386@host2.jankratochvil.net> Date: Fri, 18 Jan 2013 14:31:00 -0000 In-Reply-To: <20130117220437.GA18386@host2.jankratochvil.net> (Jan Kratochvil's message of "Thu, 17 Jan 2013 23:04:37 +0100") Message-ID: <874niebm24.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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: 2013-01/txt/msg00424.txt.bz2 Tom> I expect it will break expression parsing. Jan> Then it should be fixed but IIRC it works with the linespec parser even Jan> without quotes. I don't think we're talking about the same thing. I was contemplating the change you implied -- adding return types to all symbols. I think this change would make symbol lookup during expression parsing fail. In this case one does not include the return type in the lookup name. It works ok now precisely because the debug symbols don't include this information. Here it is without debuginfo: (gdb) p GDB::even_harder ('a') No symbol "GDB" in current context. (gdb) p 'int GDB::even_harder' ('a') $1 = 97 Tom> I think that would require too much memory for what is really a marginal Tom> feature. Jan> I find it an essential feature to be able to break on function where the Jan> application has crashed, I was using it myself several times for some C++ Jan> application (Firefox probably). Ok. I'm going to drop this patch. Tom