Loading symbol names from symbol table?

[addisoncrump]

I'm using wholesym in a BPF project to resolve stack traces. I noticed, however, that it appears that wholesym does not fallback to symbol tables when debug information is not available -- something quite limiting in my case, since debuginfo is not available for some libraries on my system.

Is this intended or am I holding it wrong?

[ishitatsuyuki]

Are you referring to the .symtab section by "fallback symbol tables"?

Many distributions ships stripped binaries — meaning the binaries only comes with .dynsyms, which contains only exported symbols. Does stack trace work with another tool, and if you know, what data source does it use to read the symbols?

[addisoncrump]

It was my own code which used object and addr2line, but switched to wholesym for lookup_offset -- the translation from file offset to symbol address was too difficult to reproduce.

[mstange]

wholesym does support falling back to the symbol table if there is no debug info for an address, and this is actually quite an important piece of functionality. It's odd that it doesn't work in your case - if you send me an example binary and example file offsets, I could take a closer look at why it doesn't.

[addisoncrump]

Sure, I'll see if I can replicate, but I've completely shifted over my strategy now (wholesym was a bit memory intensive for how I was using it) and will need to figure out a reproduction case.

[addisoncrump]

Okay, as an example: cargo! I can confirm that my local cargo has symbols, but these symbols are not resolved via file offset.

[ishitatsuyuki]

Is it the rustup cargo wrapper or the actual cargo binary?

[addisoncrump]

The actual cargo binary; I see in my stacktraces the full path, e.g.: /home/addisoncrump/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/cargo+0x11ff5fd

Curiously, I notice that binaries I build myself do get their symbols resolved... so this may be an issue with only some binaries. I'm not quite sure.

[addisoncrump]

Okay, so I observed this again with libjvm.so that was distributed with IntelliJ IDEs. Not sure I can distribute that for licensing reasons, but I confirmed that it has the symbol table. It cannot resolve the BuildID in my debuginfo cache; maybe there's some bad condition here?

$ file libjvm.so 
libjvm.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=01c51436025dae2d65e3f091184cb242a5830335, not stripped
$ nm -s libjvm.so | tail
0000000001328b20 b _ZZN9metaspace17ArenaGrowthPolicy21policy_for_space_typeEN9Metaspace13MetaspaceTypeEbE35chunk_alloc_sequence_boot_non_class
0000000001328b60 b _ZZN9metaspace17ArenaGrowthPolicy21policy_for_space_typeEN9Metaspace13MetaspaceTypeEbE35chunk_alloc_sequence_refl_non_class
0000000001328bc0 b _ZZN9metaspace17ArenaGrowthPolicy21policy_for_space_typeEN9Metaspace13MetaspaceTypeEbE35chunk_alloc_sequence_standard_class
0000000001328be0 b _ZZN9metaspace17ArenaGrowthPolicy21policy_for_space_typeEN9Metaspace13MetaspaceTypeEbE39chunk_alloc_sequence_standard_non_class
0000000001333c00 b _ZZN9SuperWord5blankEjE6blanks
00000000012f8ef8 d _ZZN9vmSymbols8find_sidEPK6SymbolE8mid_hint
0000000001364468 b _ZZNK5ZStat12should_printE15LogTargetHandleE8print_at
0000000000fcd4b0 r _ZZNK7JfrDCmd10print_helpEPKcE9signature
0000000000fcd480 r _ZZNK7JfrDCmd19argument_info_arrayEvE9signature
0000000001313a38 b _ZZNK8JfrChunk13cpu_frequencyEvE9frequency

[ishitatsuyuki]

Is it JetBrains Runtime? If so, you should be able to find the version you're running from the IDE info. Just in case, download the release from GitHub page and check if the file hashes match yours.

[addisoncrump]

This is not my issue... I would expect that, if the build id is not resolvable, it would fall back to the local symbol table.

[ishitatsuyuki]

You didn't mention how the file can be obtained, so I gave you instructions about how to link to the relevant file so others can reproduce the issue.

[addisoncrump]

Ah, my mistake. I interpreted your comment as a recommendation for the solution.