On 9/4/25 8:53 PM, Sam James wrote:
Sam James <[email protected]> writes:
Andi Kleen <[email protected]> writes:
Sam James <[email protected]> writes:
Michal Jires <[email protected]> writes:
I did handle node->iterate_referring, but forgot cnode->callers.
Only change are contents of the newly separated
mark_symbol_referenced_from_asm
Thanks, I'll try the new patch now.
With the workaround I mentioned earlier, I managed to build but got this
when booting:
Sep 04 02:04:26 mop kernel: nct6775: Unknown symbol vid_from_reg (err -2)
Likely you need a __visible to MODULE_EXPORT
This one doesn't do it, will look around more:
--- a/include/linux/export.h
+++ b/include/linux/export.h
@@ -73,7 +73,7 @@
#endif
#define __EXPORT_SYMBOL(sym, license, ns) \
- extern typeof(sym) sym; \
+ extern __visible typeof(sym) sym; \
__ADDRESSABLE(sym) \
__GENDWARFKSYMS_EXPORT(sym) \
asm(__stringify(___EXPORT_SYMBOL(sym, license, ns)))
(I tried it on the non-extern part too but then I get loads of
-Wattribute warnings.)
__ADDRESSABLE does include __used at least.
I can't yet spot where else it'd need to be, as everything relevant uses that
macro indirectly AFAICT.
I think it's because of:
commit ddb5cdbafaaad6b99d7007ae1740403124502d03
Author: Masahiro Yamada <[email protected]>
AuthorDate: Mon Jun 12 00:50:52 2023 +0900
Commit: Masahiro Yamada <[email protected]>
CommitDate: Thu Jun 22 21:17:10 2023 +0900
kbuild: generate KSYMTAB entries by modpost
-Andi
I think the issue is that modpost grabs exported symbol info from object
files which only contain our LTO data. Some of the "SILENCE" patches
disable CRC checks for the same reason.
I didn't try to make modules work yet.
Though it should work if modpost would grab symbol info from vmlinux.o
Or fat-lto might work.
__visible should not be needed outside of few edge cases.
In this case it is captured in the asm below, so definitely not needed.
Sidenote: __ADDRESSABLE's implementation guarantees symbol's existence,
but it can be renamed. I don't think it can be implemented correctly
in current GCC (so that it works both inside and outside of functions).
Fortunately it does not seem to be needed to be fixed right now.
Michal
