Hi, On Mon, 8 Jan 2018, Woodhouse, David wrote:
> > > That can be done via asm aliases or direct assembler use; the kernel > > > doesn't absolutely have to access them via C compatible symbol names. > > > > > Hi David, > > > > Can you comment on this? > > It ends up being a real pain for the CONFIG_TRIM_UNUSED_SYMBOLS > mechanism in the kernel, which really doesn't cope well with the dots. > It *does* assume that exported symbols have C-compatible names. > MODVERSIONS too, although we had a simpler "just shut up the warnings" > solution for that. It was CONFIG_TRIM_UNUSED_SYMBOLS which was the > really horrid one. > > I went a little way down the rabbit-hole of trying to make it cope, but > it was far from pretty: > > https://patchwork.kernel.org/patch/10148081/ > > If there's a way to make it work sanely, I'm up for that. But if the > counter-argument is "But someone might genuinely want to make their own > C function called __x86_indirect_thunk_rax"... I'm not so receptive to > that argument :) Well, the naming of the extern thunk isn't so important that the above might not be a reason to just go with underscores. I'll certainly not object to the patch on that basis. But do keep in mind that GCC already uses '.' for other compiler generated symbols, and we're likely to continue doing this. So eventually you'll want to fix your trim_unused infrastructure to cope with that. (Perhaps by just ignoring those symbols? It's not that they must be trimmed if unused, as the user didn't write them on his own to start with, right?) Ciao, Michael.
