On Fri, Apr 07, 2023 at 04:21:18PM -0700, Josh Poimboeuf wrote: > Anyway, I was nodding along with the above cover letter until I got to > the third paragraph. > > A "built-in kernel module" is not actually a module, as it's built in to > vmlinux. I suspect the point is that if you rebuild with a different > config, it might become a module. But many other changes could also > occur with a changed config, including changed inlining decisions and > GCC IPA optimization function renaming, in which case the symbol might > no longer exist with the new config. Yes it does not matter, for his tooling effort it was just to be able to map a possible module to a symbol so tooling can display this to disambiguate. > Also I'm confused what it means for a symbol to be "used by multiple > modules". If the same TU or inline symbol is linked into two modules, > it will be loaded twice at two different addresses, and the > implementations could even differ. He just wants to be able to map if a symbol with the same name but different addresses is due to a built-in or a module declaration of the same symbol so it can use it. > It sounds like there are two problems being conflated: > > 1) how to uniquely identify symbols in the current kernel > > For this, all we really need is file+sym. > > Or, enable -zunique-symbols in the linker. > > 2) how to uniquely identify symbols across multiple kernels/configs > > This seems much trickier, as much can change across kernels and > configs, including compiler inlining and naming decisions, not to > mention actual code changes. > > The problems are related, but distinct. > > #2 seems significantly harder to implement properly. > > Would solving #1 give you most of what you need? I'm not nick but my reading of his goals is that if you peg a "possible_module" prefix or postfix or whatever, then yes. For 2) I think it would be good to see if one could just force Kconfig tristate to add -DPOSSIBLE_MODULE, that would be an easier approach than the possible-obj-m thing [0] I had suggested last [0] https://lore.kernel.org/all/Y/kXDqW+7d71C4wz@xxxxxxxxxxxxxxxxxxxxxx/ Luis
