Dev.libfuzzer #1
Conversation
trampoline is only implemented for amd64
This provides more detailed information about the fuzzing process including the basic blocks that were covered by fuzzing
There was a problem hiding this comment.
I think that we should maybe split this into three individual PRs, possibly in this order: The 8-bit counters, the string compares, and the improved int compares with trampoline. The first two will be much easier to review and could be used by us to test the waters and get to know the process before the last one. What do you think?
kyakdan
force-pushed
the
dev.libfuzzer
branch
from
491911e to
775f8eb
Compare
| data += strconv.FormatInt(int64(n.Pos().FileIndex()), 10) | ||
| data += n.Pos().LineNumber() | ||
| data += strconv.FormatUint(uint64(n.Pos().Col()), 10) | ||
| hash := sha1.Sum([]byte(data)) |
There was a problem hiding this comment.
Rather than using sha1.Sum, we should probably create a Hash instance and write data to it, which requires no conversion to strings or allocations.
There was a problem hiding this comment.
Writing data to a Hash instance might return an error. How would you generate IDs in these cases?
There was a problem hiding this comment.
While the io.Writer interface might in general, Hash explicitly says that it never returns an error, so you can simply ignore it.
There was a problem hiding this comment.
I've overseen that comment. Will change it.
kyakdan
force-pushed
the
dev.libfuzzer
branch
from
775f8eb to
d9b8f79
Compare
kyakdan
force-pushed
the
dev.libfuzzer
branch
from
d9b8f79 to
79fdf9a
Compare
| _ = binary.Write(hash, binary.LittleEndian, int64(n.Pos().Col())) | ||
| // We also include the string representation of the node to distinguish autogenerated expression since | ||
| // those get the same `src.XPos` | ||
| _, _ = io.WriteString(hash, fmt.Sprintf("%v", n)) |
There was a problem hiding this comment.
These nodes seem to have AutoTmp() set and you may be able to get the name from .Name() directly. We should try not to rely on "%v".
There was a problem hiding this comment.
Some nodes such as ir.BinaryExpr do not have a name and we would need to traverse the children to get the names. What would be the disadvantages of relying on "%v"
There was a problem hiding this comment.
I see, it's probably better than the alternatives then. Do we still have to hash in the other fields or are they also part of the string representation?
rand.Prime does not guarantee the precise prime selection algorithm as part of its contract. For example, it changed slightly in CL 387554. We want to ensure that no tests come to rely on it staying the same, so just like other cryptographic functions that use randomness in an unspecified way (ECDSA signing, RSA PKCS #1 v1.5 encryption, RSA key generation), make it randomly read an extra byte or not. Change-Id: Ib9079c03360812d412b7c21d5a06caadabb4a8bf Reviewed-on: https://go-review.googlesource.com/c/go/+/391554 Run-TryBot: Filippo Valsorda <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> Trust: Filippo Valsorda <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]>
This PR will be imported into Gerrit with the title and first
comment (this text) used to generate the subject and body of
the Gerrit change.
Please ensure you adhere to every item in this list.
More info can be found at https://github.com/golang/go/wiki/CommitMessage
net/http: frob the quux before blarfing"This change modifies Go to ___________"
really needed (ASCII art, table, or long link)
Fixes #1234orUpdates #1234(the latter if this is not a complete fix) to this comment
golang/goyou can use theowner/repo#issue_numbersyntax:Fixes golang/tools#1234Our Gerrit server & GitHub bots enforce CLA compliance instead.