Currently a call that both accepts and creates a resource
self-justifies itself and thus is always enabled.
A good example is accept call. Accepts are always self-enable
and thus enable all other syscalls that work with the socket.
Calculate TransitivelyEnabledCalls in the opposite direction
to resolve this. Start with empty set of enable syscalls,
then enable syscalls that don't accept any resources,
then enable syscalls that accept resources created by the
previous batch of syscalls, and so on.
This prevents self-enablement of accept.
In resources.go, haveGettime is False when SyscallMap["clock_gettime"]
is nil.
In this code, there's a branch that's entered only if Gettime is False,
which appends SyscallMap["clock_gettime"] to resourceCtors. That is, it
appends nil to resourceCtors, then iterates through resourceCtors and
tries to dereference the .Name of each time, in this case, nil.Name.
This was causing a page fault on Fuchsia.
I'm not certain how the "standard" flow is supposed to work, since it
seems like any code that enters the `if cantCreate == "" && !haveGettime`
should fail... but, removing that section causes test failures, so let's
just enforce that SyscallMap["clock_gettime"] is non-nil.
If there's a better way to solve this, I'm open to suggestions.
Squash complex structs into flat byte array and mutate this array
with generic blob mutations. This allows to mutate what we currently
consider as paddings and add/remove paddings from structs, etc.
Now each prog function accepts the desired target explicitly.
No global, implicit state involved.
This is much cleaner and allows cross-OS/arch testing, etc.
