From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dd14210.kasserver.com (dd14210.kasserver.com [85.13.138.83]) by sourceware.org (Postfix) with ESMTPS id 558413857378 for ; Fri, 15 Apr 2022 12:09:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 558413857378 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=milianw.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=milianw.de Received: from agathemoarbauer.localnet (dslb-002-201-013-203.002.201.pools.vodafone-ip.de [2.201.13.203]) by dd14210.kasserver.com (Postfix) with ESMTPSA id 104BC240624 for ; Fri, 15 Apr 2022 14:09:03 +0200 (CEST) From: Milian Wolff To: elfutils-devel@sourceware.org Subject: symbol resolution differences with -flto Date: Fri, 15 Apr 2022 14:09:02 +0200 Message-ID: <1886504.tdWV9SEqCh@agathemoarbauer> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2022 12:09:06 -0000 Hey there, a user reported broken symbol resolution in hotspot/perfparser which uses elfutils when he's using it on code compiled with LTO. I think I can reproduce this, and now spent some time trying to figure out the breakage. I found at least one situation that is seemingly related to the user's issue. Below are some observation of mine and then some questions, as I cannot explain this situation and hope that someone around here has more knowledge on how to handle this correctly. First of all, the issue arises in resolving this symbol: ``` $ nm -S /home/milian/projects/compiled/kf5/lib/libKDevPlatformUtil.so. 5.8.220770 | grep addPath 000000000003d490 0000000000000207 T _ZN8KDevelop4Path7addPathERK7QString ``` In perfparser, we employ some tricks to increase symbol resolution performance. One of those is to put all symbols into a sorted list for faster lookups. I.e. we iterate over dwfl_module_getsymtab and dwfl_module_getsym_info. For the above symbol, we actually find two matches there. First the same that we obtain via `nm` above: ``` 0x3d490 0x207 _ZN8KDevelop4Path7addPathERK7QString ``` But then there's a second match for this symbol, but that one has a zero `addr` and `size` returned by `dwfl_module_getsym_info`... ``` 0x0 0x0 _ZN8KDevelop4Path7addPathERK7QString ``` I'm unsure if this is related, but it's odd for sure. To make this situation even more odd: The address we fail to resolve is at offset `0x68590` which is _very_ far away from the symbol address reported above. Yet `eu-addr2line` has no problem in resolving it, and it also claims it's not inlined? ``` eu-addr2line -f -i -C -e /home/milian/projects/compiled/kf5/lib/ libKDevPlatformUtil.so.5.8.220770 -a 68590 0x0000000000068590 KDevelop::Path::addPath(QString const&) /home/milian/projects/kde/src/kdevelop/kdevplatform/util/path.cpp:408:14 ``` How can this code location map to a symbol that is outside the range specified in the symtab? Furthermore, when I look at the dissassembly at the offset `0x68590`, then the code is seemingly in a totally different part... I.e.: ``` 0000000000068283 <_ZL9splitPathRK7QString>: ... 683bd: c3 ret void Path::addPath(const QString& path) { 683be: 55 .... 6858c: e8 fb f9 ff ff call 67f8c <_ZL9cleanPathP7QVectorI7QStringEb> } 68591: bb 01 00 00 00 mov $0x1,%ebx 68596: 48 8d 85 50 ff ff ff lea -0xb0(%rbp),%rax 6859d: 48 89 c7 mov %rax,%rdi ``` >From my understanding of the disassembly output, the function <_ZL9splitPathRK7QString> starts at 0000000000068283. But what does this `void Path::addPath` line mean - is that inlined? Why then does addr2line only show addPath and not the splitPath function it gets inlined in? It would be great if someone could educate me on how this is handled and how `0x68590` is mapped to `addPath` directly. Thanks -- Milian Wolff http://milianw.de