0

I have written a BPF program that I can install using gobpf, i.e. using their bcc tooling. While this works alright from a main package, this breaks as soon as I move it into a package for importing it as a module.

To clarify: It works with all code in package main, but as soon as I rename the package and move the main() to cmd/command.go it stops working with go run complaining that it can't find an included lib (bcc/proto.h). Incidentally, this is the same error as I always got when running gcc on my .c file without any indication I want to use BPF (the part that gobpf did for me, until I moved its invocation to a module...).

I realize this is question very specific and sits in a weird place between Go, CGo, the way C and C++ handle includes, BPF, and bcc, but I am at a loss here.

You can check out my code here https://github.com/bwNetFlow/bpfdump if that helps. It needs bcc installed in addition to go run doing its thing. Basically:

  • HEAD is the modularized version that does not work (go run cmd/dump.go)
  • HEAD~ is my initial experiment that does work (go run bpfdump.go) (you'll get an permission error as user, which is fine as it has compiled anyways).

PS: I think it might have to do with this (rather creative?) construction of bcc/proto.h: https://github.com/iovisor/bcc/blob/master/src/cc/exported_files.cc

debugloop
  • 1
  • 1
  • 1
    Probably unrelated to your actual problem, but _please_ refrain from using `go run` with filename arguments: It is a loaded footgun for any project not consisting of a single file. Get used to do `go build` (or at the very least `go run .`). – Volker Oct 12 '21 at 10:23
  • 1
    I guess the problem is that when you move your `cgo`-using code into a subpackage `cgo` generates support files (or looks them up) in a place where they do not exist. The simplest way to see it for yourself is to run `go build` with the `-x` command-line flag (as @Volker said, never ever use `go run` unless it's a single Go "script" with no frills). Consider carefully reading [the docs](https://pkg.go.dev/cmd/cgo) while paying attention to how various directories are set up and communicated to the parts of the C toolchain. – kostix Oct 12 '21 at 10:28
  • @kostix You're both almost right, thanks for the eye-opener. I usually don't call go with files directly and I don't know why I did in this instance, but then it stuck in my history... The precise issue was this sentence in the Docs you provided: "When the Go tool sees that one or more Go files use the special import "C", it will look for other non-Go files in the directory and compile them as part of the Go package." Which is what I didn't want to happen, as this C Code needs the context provided by the gobpf package. – debugloop Oct 12 '21 at 10:55

0 Answers0