From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13567 invoked by alias); 20 May 2011 20:38:16 -0000 Received: (qmail 13559 invoked by uid 22791); 20 May 2011 20:38:15 -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; Fri, 20 May 2011 20:37:59 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p4KKbxFZ011544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 20 May 2011 16:37:59 -0400 Received: from host1.jankratochvil.net (ovpn-113-104.phx2.redhat.com [10.3.113.104]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p4KKbvtc002953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 May 2011 16:37:58 -0400 Received: from host1.jankratochvil.net (localhost [127.0.0.1]) by host1.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p4KKbtPc004353; Fri, 20 May 2011 22:37:55 +0200 Received: (from jkratoch@localhost) by host1.jankratochvil.net (8.14.4/8.14.4/Submit) id p4KKbtL1004343; Fri, 20 May 2011 22:37:55 +0200 Date: Fri, 20 May 2011 20:38:00 -0000 From: Jan Kratochvil To: Keith Seitz Cc: gdb-patches@sourceware.org Subject: Re: The future of dwarf2_physname Message-ID: <20110520203755.GA3662@host1.jankratochvil.net> References: <4DD44983.7060406@redhat.com> <20110519192316.GA7075@host1.jankratochvil.net> <4DD6C6B4.7060406@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DD6C6B4.7060406@redhat.com> 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-05/txt/msg00500.txt.bz2 Hi Keith, On Fri, 20 May 2011 21:53:24 +0200, Keith Seitz wrote: > I wouldn't say that DW_AT_MIPS_linkage_name is any more ISO C++ > compliant than anything else. We still do not get to the agreement. The primary source of addresses are ELF symbols. DW_AT_low_pc+DW_AT_high_pc are ignored in many cases. (In other cases DW_AT_low_pc+DW_AT_high_pc is the only available address we have but that is offtopic here.) If you find different linkage name than DW_AT_MIPS_linkage_name then you will not find the ELF symbol and therefore GDB will fail to find the function, as I already reproduced on the sample code I provided. > Just because the compiler outputs it > does not necessarily make it sacrosanct. [gcc/33861] DW_AT_MIPS_linkage_name is fortunately or unfortunately always right because it is used for the ELF symbol. > >This is a regression. And it will always be a regression for any > >physname != DW_AT_linkage_name as with my cross-check patch it prints: > >Computed physname does not match demangled (from linkage<_ZNSt8ios_base6unsetfESt13_Ios_Fmtflags>) > > That's simply a bug. They get found, they get fixed. The sky is not falling. The sky has fallen as without that patch of mine GDB failed to find the function as I have shown before: Message-ID: <20110516154851.GA24555@host1.jankratochvil.net> During symbol reading, Computed physname does not match demangled (from linkage <_ZN1C1mEP1x>) - DIE at 0x3d [in module .../1]. (gdb) p c.m pre-phyname: $2 = {void (C *, x *)} 0x4004f0 HEAD + your patch: Cannot take address of method m. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is a regression. Until we find agreement on this point the mails do not make sense. And if you fix the specific `struct' physname problem I can find many other problems as long as any "Computed physname ... does not match demangled" message gets printed. After you fix all of the problems you will reach the functionality of my patch preferring DW_AT_MIPS_linkage_name and we can continue the discussion. > >I do not see any real regressions except incorrect testcase assumptions. > > Unless the assumption is that gdb can only set breakpoints on > linkage names, Yes. You do not always have DWARF for very every part of the program and all of its libraries, you need to stay compatible with ELF .symtab naming. > If your argument is that you don't like the way it was solved, that's an > entirely different assertion, and one with much more merit. I really do not mind which way to solve it, I would never work on GDB if I mind anything like it. But it must be able to print and break very every function in at least libstdc++so.6 and something big like /usr/lib/debug/usr/lib64/libwebkitgtk-1.0.so.debug . There are about 10000 failed lookups on it now. > Another bug slipped in. It, too, can be fixed. [That looks like a > psymtab-related bug, btw.] Yes, you can be fixing it all the following months. Or we can use DW_AT_linkage_name till the time you fix it. We need to look verify your fixes against DW_AT_linkage_name anyway. > Two maintainers believe that making the switch now is the best > approach. As far as I am concerned, the matter is closed. The problem is physname introduced some new feature - like it introduced DMGL_RET_POSTFIX-like functionality. If we go the standard demangling way we regress a bit against gdb-7.2 (but not against gdb-7.1). So I am trying to find a way to regress neither against gdb-7.1 nor against gdb-7.2. Thanks, Jan