This seems fine, and a CL would be welcome as far as I'm concerned (though I don't have direct commit access, @mikioh has the final say there).
The only thing I'm worried about is what to do about RawInstruction. By design, RawInstruction is also an Instruction, so that programmers can specify custom opcodes for forks of the BPF machine. Those instructions might not match a known instruction of the Linux BPF implementation, so... What does String() return for that?
I suppose the simplest option is simply to not implement fmt.Stringer on RawInstruction. Does that seem reasonable to you?
It is not my intend to extend the existing bpf.Instruction interface but simply implement the fmt.Stringer interface on the types (like bpf.RetConstant) where it makes sense (respectively where the assembler instruction is defined).
So I fully agree with the suggestion by @danderson to not implement fmt.Stringer on RawInstruction.
@danderson there is not yet a CL. The implementation is straight forward. Currently I am looking for the best way to implement the tests.
One possibility would be to add a go style table driven test which includes for every bpf.Instruction the expected string.
An other possibility would be to use the already existing testdata and validate, that for all instructions in testdata/all_instructions.bpf the respective line in testdata/all_instructions.txt is generated. The downside of this approach is, the instructions in testdata/all_instructions.txt do need some preprocessing (remove all lines with comments, remove empty lines a and most importantly resolve the jump labels to the correct relativ jump distance).