gocov can't instrument $GOROOT packages about gocov HOT 13 CLOSED

looking into this a bit, it's because of the way gocov instruments the package then forks to go test. The instrumented package will take precidence in $GOPATH, but will fail if the package came from $GOROOT. I think to fix this properly would require a much tighter integration with go test, probably bringing it in process with gocov.

from gocov.

Alternatively, GOROOT would have to be faked too. i.e. just like's done for the temporary GOPATH, create a temporary GOROOT, symlink everything, and instrument the GOROOT packages in there. Might want to exclude stdlib packages by default to avoid rebuilding the world all the time.

I haven't tried this, but it should work I think?

from gocov.

Roger Peppe suggested placing the annotated pkg in a different path, ie fmt -> cov/fmt, which won't be trumped by GOROOT. There may be some complications with recursive annotations, but they are probably solvable.

On 11/07/2012, at 22:53, Andrew [email protected] wrote:

Alternatively, GOROOT would have to be faked too. i.e. just like's done for the temporary GOPATH, create a temporary GOROOT, symlink everything, and instrument the GOROOT packages in there. Might want to exclude stdlib packages by default to avoid rebuilding the world all the time.

I haven't tried this, but it should work I think?

---

Reply to this email directly or view it on GitHub:
#2 (comment)

from gocov.

I like it.

from gocov.

So I went ahead and tested both approaches. The symlinked GOROOT approach seemed simple at first, until I realised that the added imports of "github.com/axw/gocov" to each instrumented package would introduce an import loop.

The approach suggested by Roger is a little more involved, but looks like it'll work. If I have some more time over the weekend I'll clean it up and commit.

from gocov.

Awesome. Looking forward to seeing your results. Being about to do
coverage checks on the std library would be a significant milestone.

On Fri, Jul 13, 2012 at 11:55 PM, Andrew Wilkins
[email protected]
wrote:

So I went ahead and tested both approaches. The symlinked GOROOT approach seemed simple at first, until I realised that the added imports of "github.com/axw/gocov" to each instrumented package would introduce an import loop.

The approach suggested by Roger is a little more involved, but looks like it'll work. If I have some more time over the weekend I'll clean it up and commit.

---

Reply to this email directly or view it on GitHub:
#2 (comment)

from gocov.

I've committed the change. You can now pass "-exclude-goroot=false" to gocov test, and it'll instrument GOROOT packages. They add enough overhead that they're disabled by default. Unfortunately, there are some packages that are always disabled: reflect, runtime, os, sync, syscall, time, testing

The problem is that the package names get changed, which changes functions' symbol names. This causes a problem in mixed Go/(non-cgo) C packages.

Also, if you happen to see nil-pointer dereference panics in gocov.Statement.At(), then it may be due to a compiler bug (waiting on confirmation): http://code.google.com/p/go/issues/detail?id=3824

from gocov.

Seems this doesn't work properly, at least for net/http. I'm not sure what exactly is causing the errors, but I think it's due to having multiple instances of the same package (e.g. because gocov imports io, we end up with an instrumented and an uninstrumented version of io.)

I have an idea for how to fix the GOROOT cycle problem, but it's horrible: remove all Go imports from gocov, and change them to C functions which refer to the external packages's function symbols explicitly, and force those packages to be loaded with a dummy package. The gocov code would then need to check for and ignore recursive calls.

... or do it all with cgo? blurgh

from gocov.

Fixed in (pending) pull request #16.

from gocov.

Fixed.

from gocov.

Oops, should mention: gocov still can't instrument the following packages: sync, sync/atomic, syscall and runtime. This is because any instrumented package must import gocov, and gocov imports those listed packages, so this would introduce a cycle. This is unlikely to ever change.

from gocov.

I think that is a reasonable limitation. With the exception of
sync{,/atomic} they don't have good tests coverage anyway.

On Tue, Jan 8, 2013 at 12:28 PM, Andrew Wilkins [email protected]:

Oops, should mention: gocov still can't instrument the following packages:
sync, sync/atomic, syscall and runtime. This is because any instrumented
package must import gocov, and gocov imports those listed packages, so this
would introduce a cycle. This is unlikely to ever change.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-11980587.

from gocov.

Batshit crazy idea, for posterity: since everything requires runtime, when instrumenting, copy the gocov sources into the runtime package and have everything point to those functions instead. Then everything can be instrumented.

from gocov.