From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18170 invoked by alias); 23 May 2011 13:17:23 -0000 Received: (qmail 18139 invoked by uid 22791); 23 May 2011 13:17:21 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_50,KAM_STOCKGEN,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_GT,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; Mon, 23 May 2011 13:17:03 +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 p4NDH3rt022672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 23 May 2011 09:17:03 -0400 Received: from host1.jankratochvil.net ([10.3.113.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p4NDH1uL014298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 May 2011 09:17:02 -0400 Received: from host1.jankratochvil.net (localhost [127.0.0.1]) by host1.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p4NDH0lD031022; Mon, 23 May 2011 15:17:00 +0200 Received: (from jkratoch@localhost) by host1.jankratochvil.net (8.14.4/8.14.4/Submit) id p4NDGxMe031021; Mon, 23 May 2011 15:16:59 +0200 Date: Mon, 23 May 2011 13:17:00 -0000 From: Jan Kratochvil To: Keith Seitz Cc: gdb-patches@sourceware.org Subject: Re: The future of dwarf2_physname Message-ID: <20110523131659.GA30344@host1.jankratochvil.net> References: <4DD44983.7060406@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <4DD44983.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/msg00524.txt.bz2 On Thu, 19 May 2011 00:34:43 +0200, Keith Seitz wrote: > I guess there are basically two options: > 1) Keep physname & apply the 12266/12506 patchset (when approved) > 2) Adopt Jan's patch and fix the fallout now > > My take on this today is that I think the least risky/most timely > solution is #1. #1 is still IMO a lot of work (see "Computed physname" errors at the end of this mail) and #1 should always be backed by #2 anyway and as #2 with current GCCs has the same user experience as #1 I do not see a reason why to wait on #1 for gdb-7.3. I have concerns about regressions for gdb-7.3, I would like to fix regressions gdb-7.1 (pre-physname) -> gdb-7.2 (physname) but possibly not introduce regressions gdb-7.2 (physname) -> gdb-7.3 (?). Trying to propose a simple DW_AT_linkage_name patch of mine but I do not yet have it finished. problem #1 of post-physname GDB (gdb) p 'f()' $1 = {long (void)} 0x4004e4 ()> (gdb) p 'long f()' $2 = {} 0x4004e4 ()> (gdb) p 'f()' No symbol "f()" in current context. (gdb) p 'long f()' $3 = {} 0x4004fb ()> ==> dis.h <== template long f () { return 1; } ==> dis1.C <== #include "dis.h" int main () { f (); } ==> dis2.C <== #include "dis.h" void g () { f (); } The two different aliases for 0x4004e4 where the $2 one does not have any type is a bug, at least both should have the same type. It can be seen also on the f() case ($3) where the return type missing alias is not present because only ELF (and not DWARF) symbol is present. I haven't found how to reproduce the regression "Cannot take address of method m." for function templates (which use the return type in their linkage) as I haven't found how to reference function template externally from a class - this field is missing there in such case: class C { public: template static long f (); }; And I get error: explicit specialization in non-namespace scope ‘class C’ for class C { public: template static long f (); template <> static long f (); }; And in other cases there is alread the template function definition with associated DWARF which gets processed by GDB-physname and the return type gets stripped. problem #2 of post-physname GDB (gdb) p 'int f()' $1 = {} 0x40050f ()> (gdb) p 'short f()' $2 = {} 0x400531 ()> (gdb) p 'f()' $3 = {int (void)} 0x40050f ()> ==> manya.C <== template int f () { return 4; } int a () { return f () == 4; } extern int b (); int main () { return a () && b () ? 0 : 1; } ==> manyb.C <== template short f () { return 2; } int b () { return f () == 2; } As the return type is stripped the name can become ambiguous. Different template functions with same name, same parameter types but different return type can be linked in a single program. It is true one cannot declare both such template functions in a single CU (Compilation Unit) so I do not expect such case is found in real world. I was trying to propose DMGL_RET_POSTFIX but it has other drawbacks and it is in fact a new feature (and not a regression fixup) because the trailing type was not present in gdb-7.2 anyway. So it can be considered after some tidy up for gdb-7.4 but it makes no sense for gdb-7.3. Re: [rfc] physname cross-check #2 http://sourceware.org/ml/gdb-patches/2011-05/msg00466.html Therefore it would apply for both ELF and both DWARF symbols producing the same form. For ELF symbols implemented by (patched) DMGL_RET_POSTFIX and for DWARF symbols missing DW_AT_linkage_name implemented by GDB-physname code. That is the 'int f()' and 'short f()' would be uniquely searchable as `f()int' and `f()short'. Still `nm -C', `objdump -C' normally do not (and even cannot) request DMGL_RET_POSTFIX therefore to be able to `break symbol_that_I_see_in_objdump_C' these DMGL_RET_POSTFIX-generated symbols should be only as aliases to also available non-DMGL_RET_POSTFIX symbols. Then there is the code for NAME_KIND_PRINT (with typedefs etc. preserved, different from NAME_KIND_PHYS with typedefs etc. resolved). That may be a nice new feature for gdb-7.4 but as such I do not find it relevant for gdb-7.3. cp_canonicalize_string_no_typedefs in decode_variable is also a nice feature (`break func(typedef)') but it is a new feature not present anytime before, therefore for gdb-7.4. Also the current NAME_KIND_PRINT behavior does not seem clearly the right one: typedef int t; void f(t p) {} int main () {} (gdb) p f $1 = {void (t)} 0x4004d4 - correct, in this CU `f' has the NAME_KIND_PRINT `t'. (gdb) info sym 0x4004d4 f(int) in section .text - correct - `info symbol' uses only minimal=ELF symbols (gdb) complete p 'f( p 'f(int) p 'f(t) - I do not find it clear this is right. There should be definitely the `f(int)' - demangled linkage name - variant. But whether to show the "convenient" aliases as SYMBOL_SEARCH_NAME I do not find clear, it may be better but it also complicates the list of all the available overloads for a function name, one should ask practical C++ programmer for it IMO. After all there is still only a single function `f': (gdb) p f(t) $2 = {void (t)} 0x4004d4 (gdb) p f(int) $3 = {void (t)} 0x4004d4 Regarding the proposals to fix dwarf2_physname computation instead of preferring DW_AT_linkage_name. ISTM we have never found the agreement with Keith, when DW_AT_linkage_name is present it is guaranteed to be correct and I do not know why not to use it. It is a good verification way to fix all the existing dwarf2_physname computation issues so that in the future one may stop shipping the redundant size-costly (3-10% of .debug files) DW_AT_linkage_name strings. But still even in future I do not see why GDB should not prefer DW_AT_linkage_name over the dwarf2_physname computated name, when it is present. Preferring dwarf2_physname computation over DW_AT_linkage_name - when they differ - means a failure to match the ELF demangled symbols leading to the error "Cannot take address of method m." and/or missing function types etc. So that way I find as always wrong. Keith proposes to fix dwarf2_physname instead of using DW_AT_linkage_name. If it really always matches sure there is no difference although (a) it still may take some time for gdb-7.3 and (b) even in the future I do not see where is any advantage over preferring DW_AT_linkage_name when it is available. Bugs to fix for /usr/lib/debug/usr/lib64/libwebkitgtk-1.0.so.0.7.0.debug from webkitgtk-debuginfo-1.4.0-1.fc15.x86_64 - it is definitely not a complete bug list, raw messages list has 56490 lines: http://people.redhat.com/jkratoch/webkitgtk-debuginfo-1.4.0-1.fc15.x86_64-gdb.err.xz Computed physname does not match demangled (from linkage <_ZN3JSC6JSCell12markChildrenERNS_9MarkStackE>) - you reported the `struct' bug is already fixed in a patch being prepared Computed physname does not match demangled (from linkage <_ZN7WebCore11lineCapNameENS_7LineCapE>) - IIRC you reported the `enum' bug is also already fixed Computed physname ::data()> does not match demangled ::data()> (from linkage <_ZN3WTF10FixedArrayIdLm8EE4dataEv>) - FYI its DW_TAG_class_type DW_AT_name is: FixedArray Computed physname ::hash(void*)> does not match demangled ::hash(void const*)> (from linkage <_ZN3WTF7PtrHashIPKvE4hashES2_>) - const issue Computed physname does not match demangled (from linkage <_ZNK7WebCore18RangeBoundaryPoint6offsetEv>) - maybe different const issue Computed physname does not match demangled (from linkage <_ZNK7WebCore8IntPointcv9_GdkPointEv>) - some leading _ Computed physname (JSC::ASTBuilder&)> does not match demangled (JSC::ASTBuilder&)> (from linkage <_ZN3JSC8JSParser19parseBreakStatementINS_10ASTBuilderEEENT_9StatementERS3_>) - missing return type etc. After all I still do not have a patch at hand but I gave some thoughts of mine on it. Thanks, Jan