tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: [golang-dev] Re: Moving Go to a newer NetBSD ABI in the 1.13 dev cycle

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 <> 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

Home | Main Index | Thread Index | Old Index