debug/xcoff: should we add this to the standard library?

[ianlancetaylor]

https://golang.org/cl/138727 proposes adding debug/xcoff to the standard library, in parallel to the existing debug/elf, debug/pe, and debug/macho packages.

@bradfitz objects, saying that debug/xcoff should be internal, and that all the other packages should be internal too if we had had internal when they were created. He proposes that they should all exist in golang.org/x/debug instead.

I tend to find these packages generally useful, and since the standard library needs them I think it's reasonable to have them in the standard library. Of course we can put them in x/debug/elf and vendor them into the standard library, but I don't see a clear reason to do that.

This needs a decision.

CC @Helflym

[ianlancetaylor]

Decision: do not add debug/xcoff to the standard library. Let's start with it in cmd/internal/xcoff.

If there is a reason to make it externally visible, let's put it in x/debug/xcoff and vendor it into cmd/vendor.

[Helflym]

This is needed by https://github.com/google/pprof which one of our teams is using (compiled by gccgo). So I think it should be put inside x/debug/xcoff.

[bradfitz]

@Helflym, in an outstanding change to pprof (link?), or already in pprof guarded by +build gccgo?

@ianlancetaylor, I'm fine with x/debug/xcoff already if you are.

[Helflym]

@bradfitz this is needed for at least this file: https://github.com/google/pprof/blob/master/internal/binutils/binutils.go.

[bradfitz]

Let's ignore pprof for a couple weeks and see AIX working first.

Just work in cmd/internal/xcoff for a few weeks until things are happy and then we can copy it to x/debug/xcofff and do the whole vendor thing.

But let's not get distracted with that right now.

You can instead just disable any pprof tests for a few weeks.

[gopherbot]

Change https://golang.org/cl/138727 mentions this issue: cmd/internal/xcoff: Add new debug package for cmd