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

[Martin Husemann <martin%NetBSD.org@localhost>]

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