Better support Go applications which are compiled without debug symbols

[grcevski]

Our current Go instrumentation for all non-Go SDK libraries will be broken when symbols are removed with -ldflags="-s -w" . Namely, when we can't find symbols we rely on our offset generator, however, the offset generator will only work for the main Go SDK, since there we can find the Go version and from there the correct offsets.

However, if the application is using an external package, we don't seem to have the correct information in the binary to tell the library version which is used. We get something like this:

time=2024-11-06T20:13:09.215Z level=DEBUG msg="can't find version for library. Assuming 0.0.0" component=goexec.structMemberOffsets function=structMemberPreFetchedOffsets lib=google.golang.org/grpc
time=2024-11-06T20:13:09.215Z level=DEBUG msg="can't find offsets for field" component=goexec.structMemberOffsets function=structMemberPreFetchedOffsets lib=google.golang.org/grpc name=google.golang.org/grpc/internal/transport.bufWriter field=offset version=0.0.0
time=2024-11-06T20:13:09.215Z level=DEBUG msg="can't find offsets for field" component=goexec.structMemberOffsets function=structMemberPreFetchedOffsets lib=google.golang.org/grpc name=google.golang.org/grpc/internal/transport.bufWriter field=buf version=0.0.0

If this is impossible to do, which I think it is, we can resort to doing what we do for the generic tracer. For example, since we have the offsets for the main Go SDK, we still have full Go support, meaning we can understand the goroutine lifecycle and we can read the data sent over the sockets. From the sockets data, we can run our protocol detector, much like we run it for other languages and produce the correct traces.

Another idea is to build logic to guess the library version, or assume the latest, which can be tricky and cause wrong data.