| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Any is the preferred over interface{} now in Go.
|
| |
|
|
|
|
|
| |
Currently the commands we have in go:generate first create an empty file
and then write final contents. This breaks any parallel builds of the source.
Even running go generate ./... does not work.
Write output files atomically.
|
| |
|
|
|
|
| |
The generator does not run and generates broken code.
It looks like the generated file was edited manully.
Fix that.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
ifuzzimpl is too lenghty and too clumsy on my taste
(nm/vmimpl worked better b/c it's shorter and used less).
I've tried to come up with something shorter and nicer.
We could use "insn" as a common name for "instruction" in ifuzz,
but it's a commonly used name already so would cause lots of conflicts.
"iset" is somewhat descriptive, short and nice.
|
| |
|
|
|
|
|
|
|
| |
ifuzzimpl imports the public interface package ifuzz
and prog package needs to import ifuzzimpl (implementation guts that
nobody outside of ifuzz should care about). This is not right.
Invert everything so that prog package only needs to import ifuzz
and ifuzz imports ifuzzimpl.
|
|
|
At the moment ifuzz only generates x86 instructions. In order to support
instruction fuzzing for others (ARM, POWERPC), some separation of
the common and arch layers is needed.
This adds 2 packages:
1. "x86" where x86 instruction generator goes to
2. "ifuzzimpl which contains some common code.
The goal was to keep changes to the rand.go to the minimum.
The next patch will use this when adding PPC64.
This should cause no behavioural change.
Signed-off-by: Alexey Kardashevskiy <aik@linux.ibm.com>
|
