On Mon, Jul 8, 2024 at 2:33 PM Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote: > > Looking at this again its not to me why Masahiro Yamada's suggestion on > that old patch series to just increase the length and put long symbols > names into its own section [0] could not be embraced with a new kconfig > option, so new kernels and new userspace could support it: > > https://lore.kernel.org/lkml/CAK7LNATsuszFR7JB5ZkqVS1W=hWr9=E7bTf+MvgJ+NXT3aZNwg@xxxxxxxxxxxxxx/ Matt, was there a reason we didn't move forward with Masahiro's proposal? It sounds reasonable to me, but I might be missing some background here. > > I am a bit scared because using hashed symbol names in backtraces, gdb, > > ... would be a nightmare. Hashes are not human readable and > > they would complicate the life a lot. And using different names > > in different interfaces would complicate the life either. > > All great points. > > The scope of the Rust issue is self contained to modversion_info, > whereas for CONFIG_LTO_CLANG issue commit 8b8e6b5d3b013b0 > ("kallsyms: strip ThinLTO hashes from static functions") describes > the issue with userspace tools (it doesn't explain which ones) > which don't expect the function name to change. This seems to happen > to static routines so I can only suspect this isn't an issue with > modversioning as the only symbols that would be used there wouldn't be > static. > > Sami, what was the exact userspace issue with CONFIG_LTO_CLANG and these > long symbols? The issue with LTO wasn't symbol length. IIRC the compiler renaming symbols with ThinLTO caused issues for folks using dynamic kprobes, and I seem to recall it also breaking systrace in Android, at which point we decided to strip the postfix in kallsyms to avoid breaking anything else. Sami
