On Tue, Nov 17, 2020 at 8:20 AM Aidan Hahn <aidan@aidanis.online> wrote:
>
> I am currently patching my local go runtime to fix a bug it has. I would like 
> to make the signal() syscall, or at least the sigaction() syscall from inside 
> the syscall package but it looks like those functions are defined as private 
> within the runtime package.
>
> I see that both SYS_SIGACTION and SYS_SIGNAL are defined in the 
> zsysnum_{os}_{arch}.go files, and it looks like these enumerations are meant 
> to be used with the RawSyscall, RawSyscall6, or rawSyscallNoError functions.
>
> My question is: how does a call to RawSyscall(SYS_SIGNAL, .....) translate to 
> a call to signal(signum, handler)? Do I add the usual arguments to signal to 
> RawSyscall and then ignore the rest?

Without more information it sounds like are on a bad path.  It's
pretty hard to imagine a case where the right fix for a runtime bug is
going to be for the syscall package to call signal or sigaction.

That said, if you really do want to call them, you need to understand
how the C library makes those system calls, and you need to do the
same thing.  Often this is indeed what you suggest: simply pass the
arguments to Syscall or RawSyscall, after converting them to uintptr.
Pass 0 for the additional arguments.

For system calls like this you are going to run into the problem that
they expect a C function pointer and you only have a Go function
value.  A Go function value is not a C function pointer.  You can try
calling reflect.Value(f).Pointer() to get something like a C function
pointer, although only if f is a package-scope function.

But once you've done that you'll have the problem that the Go function
uses a different ABI than the C function, so it won't be able to
access any of the arguments.

At that point you're pretty much going to have to use the kind of
complex code that is already in the runtime package.

So I guess this seems to me like a bad path no matter how you approach it.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVgY9vVB%2B9-DCQ%3DGYtqN51xLL%2Bj6YvTuKiiPLNE7Ed8NQ%40mail.gmail.com.

Reply via email to