bpf2go should be able to generate Go code from object files built out-of-band

[connorworley]

I'd like to have finer control of my C build, but still generate Go code using bpf2go. An option to pass in an object file rather than a source file would be helpful.

[ti-mo]

@connorworley Would you be up for implementing this? I think it's a good idea. We might use it for Cilium as well at some point. @lmb WDYT?

[lmb]

For me part of the appeal of bpf2go is that it can do things based on -target such as determining build tags automatically, etc. If we added the option to specify .o via command line we'd also have to expose the internal plumbing.

My personal preference would be to make the parts of bpf2go that are useful available via Go API so that power users can build their own tools.

[connorworley]

I could continue to allow users to specify -target, with the caveat that all specified targets share the same endianness and a check against the endianness of the object file?

[lmb]

I think that just adjusting the target flag is not enough. Here are the currently supported flags:

$  go run ./cmd/bpf2go/ -help
Usage: bpf2go [options] <ident> <source file> [-- <C flags>]

Options:

  -cc binary
    	binary used to compile C to BPF ($BPF2GO_CC) (default "clang")
  -cflags string
    	flags passed to the compiler, may contain quoted arguments ($BPF2GO_CFLAGS)
  -makebase directory
    	write make compatible depinfo files relative to directory ($BPF2GO_MAKEBASE)
  -no-global-types
    	Skip generating types for map keys and values, etc.
  -no-strip
    	disable stripping of DWARF
  -output-stem string
    	alternative stem for names of generated files (defaults to ident)
  -strip binary
    	binary used to strip DWARF from compiled BPF ($BPF2GO_STRIP)
  -tags value
    	Comma-separated list of Go build tags to include in generated files
  -target string
    	clang target(s) to compile for (comma separated) (default "bpfel,bpfeb")
  -type Name
    	Name of a type to generate a Go declaration for, may be repeated

About half of them would need custom behaviour in the "only generate go" mode. Why not just build a new tool?

[lmb]

@connorworley maybe there is a middle ground here, how does your way of compiling bpf differ from bpf2go? maybe its something we can fit into the tool itself.

[connorworley]

In short, I want to run clang-tidy on my C code with compilation options that won't diverge from bpf2go's