Recently printf.Analyzer has become stricter
(https://github.com/golang/go/issues/60529)
which led to new findings.
gvisor nogo tests run this analyzer and fail if it produces findings.
PiperOrigin-RevId: 671657227
This relaxes the checkescape annotation in the test slightly, but allowing
stack splits should not cause issues.
Fixes#7309
PiperOrigin-RevId: 436645425
This is as per proposal in #6450. I have gated this behind a tag because this
is a very sparsely used feature and otherwise will leads to a lot of unused
generated code.
Secondly, we can not generate the CheckUnmarshal method for dynamic types. So
the dynamic tag would now require its users to additionally implement
CheckUnmarshal method which is more cumbersome.
Fixes#6450
PiperOrigin-RevId: 411197734
Earlier this function was returning (int, error) much like the Copy{In/Out}
methods. The returned error was always nil. The returned int was never used.
Instead make it returned the shifted buffer which is more useful.
Updates #6450
PiperOrigin-RevId: 408268327
Change marshal.Marshallable method signatures to return the remaining buffer.
This makes it easier to implement these method manually. Without this, we would
have to manually do buffer shifting which is error prone.
tools/go_marshal/test:benchmark test does not show change in performance.
Additionally fixed some marshalling bugs in fsimpl/fuse.
Updated multiple callpoints to get rid of redundant slice indexing work and
simplified code using this new signature.
Updates #6450
PiperOrigin-RevId: 407857019
gohacks.Memmove() takes in the number of bytes to move. The current generated
code passes len(src) and len(dst) as the number of bytes to move.
However, the marshal.Marshallable interface allows passing in larger buffers.
The stated precondition is that the buffer should be "at least" SizeBytes()
in length but it is allowed to be larger.
This change now correctly calls Memmove with the argument for the number of
bytes to move as type.SizeBytes(). This was caught when I made lisafs use the
Unsafe marshalling API and got a lot of memory violations.
PiperOrigin-RevId: 368952642
Split usermem package to help remove syserror dependency in go_marshal.
New hostarch package contains code not dependent on syserror.
PiperOrigin-RevId: 365651233
We were only supporting dynamic struct types. With this change, users can make
any type dynamic. The tool (correctly) blindly just generates the remaining
methods needed to implement Marshallable using the 3 methods defined by the
user on the dynamic type.
This is helpful in situations like:
type StringArray []string
Added a test for such a use case.
PiperOrigin-RevId: 364463164
This makes it easier to implement dynamically sized types in go-marshal. You
really only need to implement MarshalBytes, UnmarshalBytes and SizeBytes to
implement the entire interface.
By using the `dynamic` tag, the autogenerator will generate the rest of the
methods for us.
This change also simplifies how KernelIPTGetEntries implements Marshallable
using the newly added utility.
PiperOrigin-RevId: 356397114
These are primarily simplification and lint mistakes. However, minor
fixes are also included and tests added where appropriate.
PiperOrigin-RevId: 351425971
CopyContext is a better name for the interface because from
go-marshal's perspective, the interface has nothing to do with a
task. A kernel.Task happens to implement the interface, but so can
other things like MemoryManager and IO sequences.
PiperOrigin-RevId: 331959678
Due to how marshallable interface implementation was generated, we could not
marshal a struct whose named started with W because there was a naming
collision with parameter (w io.Writer) and type (w *StuctName).
Used "writer" as parameter name to avoid collision.
PiperOrigin-RevId: 328343930
- All Marshal* and Unmarshal* methods now require buffers to be correctly sized
- Only the Copy{In/Out} variants can handle smaller buffers (or address spaces)
PiperOrigin-RevId: 322953881
See tools/nogo/README.md.
The checkescape tool is able to perform recursive escape analysis, using the
actual generated binary to confirm the results produced by the compiler itself.
As an initial use case, this replaces the manual escape analysis tests used for
go_marshal, and validates that the CopyIn and CopyOut paths will not require
any allocation or stack splits.
Updates #2243
PiperOrigin-RevId: 307532986
Previously, go-marshal only allowed literals for array
lengths. However, it's very common for ABI structs to have a fix-sized
array whose length is defined by a constant; for example PATH_MAX.
Having to convert all such arrays to have literal lengths is too
awkward.
PiperOrigin-RevId: 304289345
Previously, the import statement collision detection mechanism aborted
go-marshal whenever it detected two imports in any package that has
the same local name. Consider this trivial package, defined by the the
following two source files:
file1.go:
package example
import (
path/a/to/foo
)
...
file2.go:
package example
import (
another/package/with/final/component/foo
)
...
Go-marshal previously couldn't handle generating code for the the
above package, even if none of the types marked for marshalling used
either of the imported foo packages. This turns out to be too
restrictive as we run into this a lot in practice. Examples include
"encoding/binary" vs "gvisor/pkg/binary/binary", and "sync" vs
"gvisor/pkg/sync/sync".
This change allows go-marshal to proceed with marshalling, and only
abort if the code generated by go-marshal references any such
ambiguous import names.
PiperOrigin-RevId: 304131190
Andrei Vagin
gVisor bot
Shambhavi SrivastavaandgVisor bot
Adin ScannellandgVisor bot
Ayush RanjanandgVisor bot
Zach KoopmansandgVisor bot
Rahat MahmoodandgVisor bot