feat: Link the instrumented binary and run it and further check output content

[yuluo-yx]

• Fixed Link the instrumented binary and run it and further check output content in instrument_test.go #104

[y1yang0]

Could you please clarify the rationale for splitting this into two tests? I was thinking we could handle the entire process—injection, compilation, linking, and result verification—within a single test.

[yuluo-yx]

#171 (comment)

[y1yang0]

Thank you for your contribution. I'm sorry, but let's put this patch on hold for the time being.

The workflow I was expecting is: compile test.a + compile hook.a => link test.a hook.a => a.out => exec a.out.

This is different from the current approach of using go build . to build the program and capture its output. That process is essentially an integration test, which we already have covered.

Perhaps there's a fundamental issue with this requirement itself. The linking step (link test.a hook.a) cannot proceed without runtime.a. However, we are finding it difficult to get ahold of runtime.a in a reliable way. Since Go 1.20, modules cause runtime.a to be placed in the build cache (the go-build directory, i.e., GOCACHE) instead of the old $GOPATH/pkg location. This change further complicates the task.