On Mon, 2018-01-08 at 09:25 -0800, H.J. Lu wrote: > On Mon, Jan 8, 2018 at 9:18 AM, Michael Matz <m...@suse.de> wrote: > > > > Hi, > > > > On Mon, 8 Jan 2018, H.J. Lu wrote: > > > > > > > > On Mon, Jan 8, 2018 at 4:00 AM, Jakub Jelinek <ja...@redhat.com> wrote: > > > > > > > > On Mon, Jan 08, 2018 at 03:55:52AM -0800, H.J. Lu wrote: > > > > > > > > > > > > > > > > > I'm wondering whether thunk creation can be a good > > > > > > target-independent generalization? I guess > > > > > > we can emit the function declaration without direct writes to > > > > > > asm_out_file? And the emission > > > > > > of function body can be potentially a target hook? > > > > > > > > > > > > What about emitting body of the function with RTL instructions > > > > > > instead of direct assembly write? > > > > > > My knowledge of RTL is quite small, but maybe it can bring some > > > > > > generalization and reusability > > > > > > for other targets? > > > > > Thunks are x86 specific and they are created the same way as 32-bit > > > > > PIC thunks. > > > > > I don't see how a target hook is used. > > > > Talking about PIC thunks, those have I believe . character in their > > > > symbols, > > > > so that they can't be confused with user functions. Any reason these > > > > retpoline thunks aren't? > > > > > > > They used to have '.'. It was changed at the last minute since kernel > > > needs to export them as regular symbols. > > 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 :)
smime.p7s
Description: S/MIME cryptographic signature
