symbol resolution differences with -flto

symbol resolution differences with -flto

[Milian Wolff]

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

Re: symbol resolution differences with -flto

[Milian Wolff]

[-- Attachment #1: Type: text/plain, Size: 935 bytes --]

On Freitag, 15. April 2022 14:09:02 CEST Milian Wolff wrote:
> 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.

To answer my own question: The issue arises for functions with debug 
information that are not exported. Those won't have an entry in the symbol 
table, but by looking at the dwarf information we can still assign them a 
scope name from the respective DIEs, just like one would do for inline frames 
too.

Cheers
-- 
Milian Wolff
mail@milianw.de
http://milianw.de

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]