From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31032 invoked by alias); 5 Jun 2011 20:26:39 -0000 Received: (qmail 31022 invoked by uid 22791); 5 Jun 2011 20:26:39 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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; Sun, 05 Jun 2011 20:26:19 +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 p55KQJNb012238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 5 Jun 2011 16:26:19 -0400 Received: from host1.jankratochvil.net (ovpn-113-49.phx2.redhat.com [10.3.113.49]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p55KQHEq025087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 5 Jun 2011 16:26:18 -0400 Received: from host1.jankratochvil.net (localhost [127.0.0.1]) by host1.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p55KQGLt007697 for ; Sun, 5 Jun 2011 22:26:16 +0200 Received: (from jkratoch@localhost) by host1.jankratochvil.net (8.14.4/8.14.4/Submit) id p55KQF91007691 for gdb-patches@sourceware.org; Sun, 5 Jun 2011 22:26:15 +0200 Date: Sun, 05 Jun 2011 20:26:00 -0000 From: Jan Kratochvil To: gdb-patches@sourceware.org Subject: [patch 0/2] physname reg.: C++ breakpoints / linespec fixes Message-ID: <20110605202615.GA20427@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2011-06/txt/msg00078.txt.bz2 Hi, as discussed in the "The future of dwarf2_physname" thread GDB lost the ability to fallback to minimal symbols (ELF .symtab & co.) from full symbols (DWARF .debug_info etc.) in some cases, due to physname: - if (paren_pointer == NULL) - return decode_compound (argptr, funfirstline, canonical, change into unconditional - approx.: + return decode_compound (argptr, funfirstline, canonical, [patch 1/2] One reason if there are some bugs and/or discrepancies between GCC, DWARF and GDB regarding DWARF which is sometimes even missing DW_AT_linkage_name. The minimal symbols are at least one way how to `break' at some function. Another point is that sometimes the DWARF is missing, either for parts of the app compiled without -g or for system libraries which do not have separate debug info installed. [patch 2/2] Another problem is "Junk at end of arguments." for more complicated function specifiers. It is due to the physname patch part: - else if (paren_pointer != NULL) - { - p = paren_pointer + 1; - } The idea here is instead of chasing which every string can still be a part of the function specification (as being done by current physname code) one can rather to stop on any string which looks as a linespec stopper. It would be a problem if it could be ambiguous but I haven't found any countercase, would you? That is: * it is worse to parse "operator()" and leave "(int)" there causing "Junk at end of arguments." instead of the failure case of the proposed code: * possibly consider whole "funcname threaf 1" (`threaf' is a `thread' typo) as a function name failing to look up symbol "funcname threaf 1". It just leads to a different error type but it would end up by an error anyway. I have not addressed specific PRs, I was addressing to have no regressions against pre-physname GDB, that is to the FSF gdb-7.1 state, before: commit 42284fdf9d8cdb20c8e833bdbdb2b56977fea525 Author: Keith Seitz Date: Tue Mar 9 18:09:04 2010 +0000 dwarf2_physname patchset: as tested by my gdb-breakpoint*.pl scripts posted at: Re: [RFA] 12266 (typedef'd parameters) revisited again http://sourceware.org/ml/gdb-patches/2011-06/msg00067.html that is to be able to at least: (gdb) break 'function name as seen in nm -C' So far I have not tried to test regressions without quotes but (a) hopefully it also works and (b) adding quotes should be users be used to as a workaround, it is worse if one cannot figure out how to putsthe breakpoint. I understand all the various bugs in decode_compound code (such as the one about `operator ()') and in physname mangling etc. can be fixed but these two patches try to address it in a generic way. linespec is IMNSHO a hack anyway and one day it should be merged with the general expression parser (used for example for `print'); which should be further merged with GCC/G++ parser. Expression Parser Plug-In Available http://sourceware.org/ml/archer/2011-q1/msg00122.html So the goal here is to get no regressions with gdb-breakpoint*.pl scripts, I did not try to summarize all the regression types to create a GDB testcase for each of them. The new testcases are only illustrative for the specific fixes FAIL->PASS, I was not trying to address each specific problems by this patchset anyway. Thanks, Jan