On 08.03.2019 09:52, Martin Husemann wrote: > On Thu, Mar 07, 2019 at 05:01:20PM -0800, Ian Lance Taylor wrote: >> On Thu, Mar 7, 2019 at 7:32 AM Kamil Rytarowski <n54%gmx.com@localhost> wrote: >>> >>> On 07.03.2019 10:48, Benny Siegert wrote: >>> >>>> Any comments, objections, etc. from Go or NetBSD folks? >>>> >>> >>> We should switch to libc calls and reduce users of syscall(2)/__syscall(2). >> >> Go does work that way on Darwin, Solaris, AIX, and Windows. It has an >> efficiency cost--Go programs run somewhat slower--and it means that >> someone has to write a bunch of near-boilerplate code (see, e.g., >> runtime/sys_darwin.go). Is there a reason to go this route for >> NetBSD? Is NetBSD trying to avoid statically linked executables? > > This is unrelated to statically linked executables (we do provide > a static libc). > > The point is more the very fragile syscall API, especially when you try > to write portable code (that is: same syscall, but portable over a variety > of architectures). > > We have for example this hack in our __syscal test in the NetBSD test suite: > > #if !defined(_LP64) && BYTE_ORDER == _BIG_ENDIAN > #define __SYSCALL_TO_UINTPTR_T(V) ((uintptr_t)((V)>>32)) > #else > #define __SYSCALL_TO_UINTPTR_T(V) ((uintptr_t)(V)) > #endif > > and then do this to invoke mmap via __syscall: > > p = (const char *)__SYSCALL_TO_UINTPTR_T(__syscall(SYS_mmap, > 0, sizeof(secrect_data), PROT_READ, MAP_PRIVATE, fd, > /* pad*/ 0, (off_t)0)); > > So overall this is considered a hack (or at least very ugly), and using > the (static) libc stub is a lot easier to get right and portable. > Of course this mostly applies to C usage, and if you got the go glue > code right for an architecture once, you are done ;-) > > Martin > This is right. It's hard to write portable code to multiple ABIs using syscall(2)/__syscall(2) hack. It's also not possible to express all types of syscalls (returning multiple values). In my opinion, slight cost of performance is superior to maintenance burden of indirect syscall API in C. We had to switch sanitizers to libc calls, because there were too many issues with syscall(2)/__syscall(2). There were also discussions about dropping this API from newer kernels (I support it), and we need to switch current users away.
Attachment:
signature.asc
Description: OpenPGP digital signature