[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <39d68044-2641-75da-929a-f5e852f0a3d0@gnuweeb.org>
Date: Thu, 29 Dec 2022 18:41:59 +0700
From: Ammar Faizi <ammarfaizi2@...weeb.org>
To: Willy Tarreau <w@....eu>
Cc: "Paul E. McKenney" <paulmck@...nel.org>,
Shuah Khan <shuah@...nel.org>,
Gilang Fachrezy <gilang4321@...il.com>,
VNLX Kernel Department <kernel@...x.org>,
Alviro Iskandar Setiawan <alviro.iskandar@...weeb.org>,
Kanna Scarlet <knscarlet@...weeb.org>,
Muhammad Rizki <kiizuha@...weeb.org>,
GNU/Weeb Mailing List <gwml@...r.gnuweeb.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Kselftest Mailing List
<linux-kselftest@...r.kernel.org>
Subject: Re: [RFC PATCH v1 0/8] nolibc signal handling support
On 12/28/22 8:35 PM, Willy Tarreau wrote:
> OK thanks!
>
> I've pushed for you an update which starts to do what I proposed. Errno
> and environ are now marked weak for all archs, and _auxv is set for i386,
> x86_64, arm64 and arm for now:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/nolibc.git/log/?h=20221227-nolibc-weak-2
>
> You can already use it to implement getauxval(), it will normally work
> for these archs.
Will do and be back with two patch series.
> I think we could avoid the asm specific stuff is we get rid of the frame
> pointer. Please look below:
>
> __attribute__((weak,unused,noreturn,optimize("omit-frame-pointer"),section(".text.nolibc_rt_sigreturn")))
> void sys_rt_sigreturn()
> {
> my_syscall0(__NR_rt_sigreturn);
> __builtin_unreachable();
> }
Wow! You just taught me that we can force optimize a function with
optimize("omit-frame-pointer") attribute. Nice to know this one!
I compile-tested it and it indeed gives the correct code on x86-64.
Hopefully this approach works for all archs.
> It gives me the correct code for x86_64 and i586. I don't know if other
> architectures will want to add a prologue. I tried with "naked" but it's
> ignored by the compiler since the function is not purely asm. Not very
> important but given that we already have everything to perform our calls
> it would make sense to stay on this. By the way, for the sake of
> consistency with other syscalls, I do think the function (or label if
> we can't do otherwise) should be called "sys_rt_sigreturn" as it just
> performs a syscall.
Will call that 'sys_rt_sigreturn' in the next series.
Thanks!
--
Ammar Faizi
Powered by blists - more mailing lists