On Sat, 2024-10-19 at 13:54 +0800, David Gow wrote: > > Okay, it turns out this breaks clang: > arch/um/kernel/skas/stub_exe.c:84:2: error: non-ASM statement in naked > function is not supported
Fun :) Interesting too, I've _definitely_ got some code elsewhere, that's usually compiled with clang, using __attribute__((naked,noinline)). With a quite old clang version, I believe. Oh well, whatever. > And, looking into it, gcc's docs are not encouraging here either: > https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html > > This attribute allows the compiler to construct the requisite function > declaration, while allowing the body of the function to be assembly > code. The specified function will not have prologue/epilogue sequences > generated by the compiler. Only basic asm statements can safely be > included in naked functions (see Basic Asm — Assembler Instructions > Without Operands). While using extended asm or a mixture of basic asm > and C code may appear to work, they cannot be depended upon to work > reliably and are not supported. Right ... > My gut feeling is that the "correct" way of doing this is to use an > actual crt implementation for __start. I managed to get it working > with nolibc on x86_54, but the sheer amount of hackery involved was > not exactly encouraging. There are a lot of conflicts between the > different headers for a start. Yeah, that doesn't seem like a lot of fun. > The other "correct" way would be to rewrite __start in assembly, which > is annoying as it'd be architecture specific, so need a separate > 32-bit version. That'd probably be less bad than it sounds, since all the syscall magic macros etc. in there are already architecture specific. > The less-correct-but-working-here way, which I'm tempted by for now, > is to get rid of __attribute__((naked)) and just use > __attribute__((force_arg_align_pointer)). That's probably the best way > of fixing the stack issue, but obviously won't fix any other issues > which could arise from __start playing loose with the rules. > > My current plan is to send out a v2 with force_arg_align_pointer next > week, unless someone has a more brilliant idea. Sounds good to me. We'll find out if we have to iterate more ;) johannes
