Open brson opened 1 year ago
After further experiments I don't think stripping solves my problems from https://github.com/solana-labs/move/issues/303.
Stripping does not remove symbol names from the dynamic symbol table (.dynsym), and that is where the large symbols are.
So this is probably still needed for production, but does not solve my immediate problems.
In rbpf-tests.rs the linker command already adds an option to strip all symbols. We might have to keep move-native symbols short or replace them by hashes, assuming we can avoid collisions.
We already strip all symbols that are not exported.
When move build
links the final .so
file it strips all the symbols. https://github.com/solana-labs/move/blob/eda1dcf69a816a2732d88a80d6f31b459d775066/language/solana/move-to-solana/src/lib.rs#L275
and this is in rbpf-tests.rs when linking the final binary https://github.com/solana-labs/move/blob/eda1dcf69a816a2732d88a80d6f31b459d775066/language/tools/move-mv-llvm-compiler/tests/rbpf-tests.rs#L278
yeah i remember we ran into this issue only a while back and @dmakarov found out this issue with long symbol names. I we'll get linker error if long symbol names are present in a binary for some reason.
rbpf does not allow symbol names greater than 64 bytes, and in https://github.com/solana-labs/move/issues/303 I have needed to generate symbol names larger than that. rustc generates huge symbol names but they are stripped before running on solana.
It seems that we have just been lucky that move-native has not generated any huge symbol names, as that library is not stripped.
Solana does this in the
cargo-build-sbf
tool by using itsstrip.sh
script. That script essentially just callsllvm-objcopy --strip-all
on the .so file.I am unsure where exactly we should do this. For now we might be able to just do it in rbpf-tests.