From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 860C9386EC42 for ; Fri, 24 Apr 2020 18:09:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 860C9386EC42 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tdevries@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id E4FBEACF3; Fri, 24 Apr 2020 18:09:05 +0000 (UTC) Subject: Re: [PATCH 08/10] Use the linkage name if it exists From: Tom de Vries To: Tom Tromey , gdb-patches@sourceware.org References: <20200325200715.12947-1-tom@tromey.com> <20200325200715.12947-9-tom@tromey.com> Autocrypt: addr=tdevries@suse.de; keydata= xsBNBF0ltCcBCADDhsUnMMdEXiHFfqJdXeRvgqSEUxLCy/pHek88ALuFnPTICTwkf4g7uSR7 HvOFUoUyu8oP5mNb4VZHy3Xy8KRZGaQuaOHNhZAT1xaVo6kxjswUi3vYgGJhFMiLuIHdApoc u5f7UbV+egYVxmkvVLSqsVD4pUgHeSoAcIlm3blZ1sDKviJCwaHxDQkVmSsGXImaAU+ViJ5l CwkvyiiIifWD2SoOuFexZyZ7RUddLosgsO0npVUYbl6dEMq2a5ijGF6/rBs1m3nAoIgpXk6P TCKlSWVW6OCneTaKM5C387972qREtiArTakRQIpvDJuiR2soGfdeJ6igGA1FZjU+IsM5ABEB AAHNH1RvbSBkZSBWcmllcyA8dGRldnJpZXNAc3VzZS5kZT7CwKsEEwEIAD4WIQSsnSe5hKbL MK1mGmjuhV2rbOJEoAUCXSW0JwIbAwUJA8JnAAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAh CRDuhV2rbOJEoBYhBKydJ7mEpsswrWYaaO6FXats4kSgc48H/Ra2lq5p3dHsrlQLqM7N68Fo eRDf3PMevXyMlrCYDGLVncQwMw3O/AkousktXKQ42DPJh65zoXB22yUt8m0g12xkLax98KFJ 5NyUloa6HflLl+wQL/uZjIdNUQaHQLw3HKwRMVi4l0/Jh/TygYG1Dtm8I4o708JS4y8GQxoQ UL0z1OM9hyM3gI2WVTTyprsBHy2EjMOu/2Xpod95pF8f90zBLajy6qXEnxlcsqreMaqmkzKn 3KTZpWRxNAS/IH3FbGQ+3RpWkNGSJpwfEMVCeyK5a1n7yt1podd1ajY5mA1jcaUmGppqx827 8TqyteNe1B/pbiUt2L/WhnTgW1NC1QDOwE0EXSW0JwEIAM99H34Bu4MKM7HDJVt864MXbx7B 1M93wVlpJ7Uq+XDFD0A0hIal028j+h6jA6bhzWto4RUfDl/9mn1StngNVFovvwtfzbamp6+W pKHZm9X5YvlIwCx131kTxCNDcF+/adRW4n8CU3pZWYmNVqhMUiPLxElA6QhXTtVBh1RkjCZQ Kmbd1szvcOfaD8s+tJABJzNZsmO2hVuFwkDrRN8Jgrh92a+yHQPd9+RybW2l7sJv26nkUH5Z 5s84P6894ebgimcprJdAkjJTgprl1nhgvptU5M9Uv85Pferoh2groQEAtRPlCGrZ2/2qVNe9 XJfSYbiyedvApWcJs5DOByTaKkcAEQEAAcLAkwQYAQgAJhYhBKydJ7mEpsswrWYaaO6FXats 4kSgBQJdJbQnAhsMBQkDwmcAACEJEO6FXats4kSgFiEErJ0nuYSmyzCtZhpo7oVdq2ziRKD3 twf7BAQBZ8TqR812zKAD7biOnWIJ0McV72PFBxmLIHp24UVe0ZogtYMxSWKLg3csh0yLVwc7 H3vldzJ9AoK3Qxp0Q6K/rDOeUy3HMqewQGcqrsRRh0NXDIQk5CgSrZslPe47qIbe3O7ik/MC q31FNIAQJPmKXX25B115MMzkSKlv4udfx7KdyxHrTSkwWZArLQiEZj5KG4cCKhIoMygPTA3U yGaIvI/BGOtHZ7bEBVUCFDFfOWJ26IOCoPnSVUvKPEOH9dv+sNy7jyBsP5QxeTqwxC/1ZtNS DUCSFQjqA6bEGwM22dP8OUY6SC94x1G81A9/xbtm9LQxKm0EiDH8KBMLfQ== Message-ID: <08f5f9ed-49d8-e8f3-c186-52c91c496f14@suse.de> Date: Fri, 24 Apr 2020 20:09:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-28.5 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 18:09:09 -0000 On 24-04-2020 18:06, Tom de Vries wrote: > On 25-03-2020 21:07, Tom Tromey wrote: >> The DWARF reader has had some odd code since the "physname" patches landed. >> >> In particular, these patches caused PR symtab/12707; namely, they made >> it so "set print demangle off" no longer works. >> >> This patch attempts to fix the problem. It arranges to store the >> linkage name on the symbol if it exists, and it changes the DWARF >> reader so that the demangled name is no longer (usually) stored in the >> symbol's "linkage name" field. >> >> c-linkage-name.exp needed a tweak, because it started working >> correctly. This conforms to what I think ought to happen, so this >> seems like an improvement here. >> >> compile-object-load.c needed a small change to use >> symbol_matches_search_name rather than directly examining the linkage >> name. Looking directly at the name does the wrong thing for C++. >> >> There is still some name-related confusion in the DWARF reader: >> >> * "physname" often refers to the logical name and not what I would >> consider to be the "physical" name; >> >> * dwarf2_full_name, dwarf2_name, and dwarf2_physname all exist and >> return different strings -- but this seems like at least one name >> too many. For example, Fortran requires dwarf2_full_name, but other >> languages do not. >> >> * To my surprise, dwarf2_physname prefers the form emitted by the >> demangler over the one that it computes. This seems backward to me, >> given that the partial symbol reader prefers the opposite, and it >> seems to me that this choice may perform better as well. >> >> I didn't attempt to clean up these things. It would be good to do, >> but whenever I contemplate it I get caught up in dreams of truly >> rewriting the DWARF reader instead. >> > > Hi, > > As you mentioned on IRC, there's a regression with > gdb.dwarf2/dw2-bad-mips-linkage-name.exp and target board > cc-with-debug-names. I tracked that down to this patch in the series. > > Using readelf -w, I can read the .debug_names section, and see without > this patch: > ... > [ 6] #0002b60b f: <3> DW_TAG_subprogram DW_IDX_compile_unit=3 > DW_IDX_GNU_internal=1 > [ 8] #0002b60c g: <3> DW_TAG_subprogram DW_IDX_compile_unit=3 > DW_IDX_GNU_internal=1 > ... > and with this patch: > ... > [ 6] #0ef9dc4b _Z1fv: <3> DW_TAG_subprogram DW_IDX_compile_unit=3 > DW_IDX_GNU_internal=1 > [ 8] #0002b60c g: <3> DW_TAG_subprogram DW_IDX_compile_unit=3 > DW_IDX_GNU_internal=1 > ... > > So we end up with the mangled name for f in the index. That looks > significant, but I'm not sure yet if that is the reason why we're not > able to print the type of f. > Hmm, one thing that is odd about this test-case is that it constructs a C language CU, which contains a subprogram with DW_AT_MIPS_linkage_name attribute with a C++ mangled name. If I update the testcase to use a c++ language CU, the test passes: ... diff --git a/gdb/testsuite/gdb.dwarf2/dw2-bad-mips-linkage-name.exp b/gdb/testsuite/gdb.dwarf2/dw2-bad-mips-lin kage-name.exp index d00308a5702..5f01c41aaa3 100644 --- a/gdb/testsuite/gdb.dwarf2/dw2-bad-mips-linkage-name.exp +++ b/gdb/testsuite/gdb.dwarf2/dw2-bad-mips-linkage-name.exp @@ -38,7 +38,7 @@ Dwarf::assemble $asm_file { cu {} { DW_TAG_compile_unit { - {DW_AT_language @DW_LANG_C} + {DW_AT_language @DW_LANG_C_plus_plus} {DW_AT_name dw2-bad-mips-linkage-name.c} {DW_AT_comp_dir /tmp} @@ -78,5 +78,5 @@ if { [prepare_for_testing "failed to prepare" ${testfile} \ # much matter what we test here, so long as we do something to make # sure that the DWARF is read. -gdb_test "ptype f" " = bool \\(\\)" -gdb_test "ptype g" " = bool \\(\\)" +gdb_test "ptype f" " = bool \\(void\\)" +gdb_test "ptype g" " = bool \\(void\\)" ... Thanks, - Tom