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

[maya%netbsd.org@localhost]

On Fri, Mar 08, 2019 at 10:24:14AM +0100, Martin Husemann wrote:
> On Fri, Mar 08, 2019 at 10:22:07AM +0100, Kamil Rytarowski wrote:
> > In my opinion, slight cost of performance is superior to maintenance
> > burden of indirect syscall API in C.
> 
> I am not sure where this slight performance hit would come from, especially in
> the context of statically linked binaries.
> 
> Martin

The proposed options for this scenario (judging by the Darwin code) are:
Go code -> Go ABI to C ABI translation -> syscall stub in libc -> syscall

vs.
Go code -> Go ABI syscall stub -> syscall

(wild option for portability but not compatibility*, using the
Syscall{,6,9} functions with SYS_syscall more, which is probably less
heavy)

* Which we won't gain anyway, see:
http://mail-index.netbsd.org/tech-pkg/2019/03/08/msg020917.html