h,
> but it shouldn't be all that costly. Famous last words, of course...
>
> Does anybody see fundamental problems with that?
I think this would be a good idea. I have been working on a patchset
to clean up the conditional syscall handling (sys_ni.c), and conflicts
with the prototypes in syscalls.h have been getting in the way.
Having the prototypes use SYSCALL_DECLAREx(...) would solve that
issue.
--
Brian Gerst
ariants through copy and paste.
> smart compiler to d
>
> > I don't really understand
> > the comment, why can't this just use this?
>
> That errors out with:
>
> ld: arch/x86/entry/syscall_x32.o:(.rodata+0x1040): undefined reference to
> `__x32_sys_execve'
> ld: arch/x86/entry/syscall_x32.o:(.rodata+0x1108): undefined reference to
> `__x32_sys_execveat'
> make: *** [Makefile:1139: vmlinux] Error 1
I think I have a fix for this, by modifying the syscall wrappers to
add an alias for the __x32 variant to the native __x64_sys_foo().
I'll get back to you with a patch.
--
Brian Gerst
ry] Error 2
> make[1]: *** Waiting for unfinished jobs
> kernel/exit.o: warning: objtool: __x64_sys_exit_group()+0x14: unreachable
> instruction
> make: *** [Makefile:1764: arch/x86] Error 2
> make: *** Waiting for unfinished jobs
If you move those aliases above all the __SYSCALL_* defines it will
work, since that will get the forward declaration too. This would be
the simplest workaround.
--
Brian Gerst
On Mon, Jun 15, 2020 at 2:47 PM Arnd Bergmann wrote:
>
> On Mon, Jun 15, 2020 at 4:48 PM Brian Gerst wrote:
> > On Mon, Jun 15, 2020 at 10:13 AM Christoph Hellwig wrote:
> > > On Mon, Jun 15, 2020 at 03:31:35PM +0200, Arnd Bergmann wrote:
>
> > >
> > >
# fake return address to stop unwinder
> + call1f # put return address on stack for unwinder
> +1: xorq%rbp, %rbp # clear frame pointer
> + movqinitial_code(%rip), %rax
> pushq $__KERNEL_CS# set correct cs
>
t; TIF_RESTORE_SIGMASK defines.
There is a small typo in the subject, should be "signal: Consolidate
{TS,TIF}_RESTORE_SIGMASK code"
--
Brian Gerst
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
