On Fri 08 Mar 2019 at 13:58:02 +0100, Aram H?v?rneanu wrote: > The overhead doesn't come from the ABI translation, but it comes > from the Go runtime. If libc is not used, Go can do system calls > on Go stacks. If libc is used, Go can't do system calls on Go stack, > it needs to switch to a C-compatible stack. Before switching to a > C stack, the Go program must inform the runtime of this, then, the > runtime will take certain actions. Similarly, after return from > system call, Go will switch stacks and the runtime must be informed > again and it will take other actions. Just out of curiosity, doesn't Go follow the ABI as established for the CPU? I'm not sure where it is formally described, but https://wiki.osdev.org/System_V_ABI seems a fairly general location. Or maybe https://software.intel.com/sites/default/files/article/402129/mpx-linux64-abi.pdf for more a x86_64-only version. These documents describe function calling conventions, including stack layout. I would expect that if the established ABI is followed, then stacks are compatible. Or am I too optimistic? -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond
Attachment:
signature.asc
Description: PGP signature