cmd/link: coverage analysis fail when using CGO & LLVM/clang 12 #58848
Comments
gopherbot
added
the
compiler/runtime
|
Change https://go.dev/cl/473115 mentions this issue: |
|
Where it it created for future reference: https://github.com/llvm/llvm-project/blob/3bc76339ea887e903d3e72f0e973d117d9c69c35/clang/lib/CodeGen/CoverageMappingGen.cpp#L1643 |
thanm
added
WaitingForInfo
|
Thanks for the report. It would be helpful if you could post the C flags that are being used for this build (e.g. what's being passed to the C compiler when the various CGO C files are compiled). Also, I am curious as to what happens if you switch to external linking (e.g. "-ldflags=-linkmode=external"), whether that also resolve the issue. |
|
Thank you for the quick reply! I belive that I'll see if I can convince bazel to run with |
|
It looks like passing |
|
@gopherbot, please remove label WaitingForInfo |
gopherbot
removed
the
WaitingForInfo
|
Thanks. The failure with -linkmode=external is surprising -- would you mind posting the error output for that? |
|
Yeah, that was a bit surprising to me as well. I get the same error output from |
|
The And with |
|
Hmm, based on what I am seeing I think the "ldflags=-linkmode=external" is maybe not making it through to the Go command... the reason I say this is that the "loadelf" routines in question (which are generating the errors) are only invoked during internal linking. Here's a toy program that uses the and here is a script I can use to compile it. Note the use of If I do a build with "-ldflags=-linkmode=external" this works fine (external linker can handle the sections generated by the coverage flags), whereas if I build with "-ldflags=-linkmode=internal" I get the same sorts of errors that you are seeing with your bazel build. Eg See also related issues #58619 and #58620, similar things are happening there. The best fix for all these problems is to make sure that we wind up using the external linker, as opposed to continuing to use the internal linker and teaching it to deal with the various quirks in host objects. I am working on a CL 471055 that will help solve these problems using the Go command, however in your case you are building with bazel, so we either need a bazel fix or we need some other fix in the Go toolchain (possibly the cgo command). |
Interesting, as a simple test I did change to
Yeah, as far as I've seen |
|
Change https://go.dev/cl/475375 mentions this issue: |
This patch changes the Go command to examine the set of compiler
flags feeding into the C compiler when packages that use cgo are built.
If any of a specific set of strange/dangerous flags are in use,
then the Go command generates a token file ("preferlinkext") and
embeds it into the compiled package's archive.
When the Go linker reads the archives of the packages feeding into the
link and detects a "preferlinkext" token, it will then use external
linking for the program by default (although this default can be
overridden with an explicit "-linkmode" flag).
The intent here is to avoid having to teach the Go linker's host object
reader to grok/understand the various odd symbols/sections/types that
can result from boutique flag use, but rather to just boot the objects
in question over to the C linker instead.
Updates #58619.
Updates #58620.
Updates #58848.
Change-Id: I56382dd305de8dac3841a7a7e664277826061eaa
Reviewed-on: https://go-review.googlesource.com/c/go/+/475375
Reviewed-by: Cherry Mui <[email protected]>
Reviewed-by: Bryan Mills <[email protected]>
Run-TryBot: Than McIntosh <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
|
Update: I have submitted CL 475375, which should take care of the problem for "go test". If you can test this CL (or latest tip of go repo) to see if it fixes the problem, that would be great. |
|
Super! I tested with Are there any slim chances that CL 475375 gets back ported to 1.20? As it seems to prevent others from updating to Go 1.20 too. |
|
Thanks for verifying. I'll request a backport-- it will need to be reviewed/approved by the release team, however, so no guarantees. |
|
Change https://go.dev/cl/476576 mentions this issue: |
|
Change https://go.dev/cl/476577 mentions this issue: |
… strange cgo flags seen
This patch changes the Go command to examine the set of compiler
flags feeding into the C compiler when packages that use cgo are built.
If any of a specific set of strange/dangerous flags are in use,
then the Go command generates a token file ("preferlinkext") and
embeds it into the compiled package's archive.
When the Go linker reads the archives of the packages feeding into the
link and detects a "preferlinkext" token, it will then use external
linking for the program by default (although this default can be
overridden with an explicit "-linkmode" flag).
The intent here is to avoid having to teach the Go linker's host object
reader to grok/understand the various odd symbols/sections/types that
can result from boutique flag use, but rather to just boot the objects
in question over to the C linker instead.
Fixes #59051.
Updates #58619.
Updates #58620.
Updates #58848.
Change-Id: I56382dd305de8dac3841a7a7e664277826061eaa
Reviewed-on: https://go-review.googlesource.com/c/go/+/475375
Reviewed-by: Cherry Mui <[email protected]>
Reviewed-by: Bryan Mills <[email protected]>
Run-TryBot: Than McIntosh <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
(cherry picked from commit 035db07)
Reviewed-on: https://go-review.googlesource.com/c/go/+/476577
… strange cgo flags seen
This patch changes the Go command to examine the set of compiler
flags feeding into the C compiler when packages that use cgo are built.
If any of a specific set of strange/dangerous flags are in use,
then the Go command generates a token file ("preferlinkext") and
embeds it into the compiled package's archive.
When the Go linker reads the archives of the packages feeding into the
link and detects a "preferlinkext" token, it will then use external
linking for the program by default (although this default can be
overridden with an explicit "-linkmode" flag).
The intent here is to avoid having to teach the Go linker's host object
reader to grok/understand the various odd symbols/sections/types that
can result from boutique flag use, but rather to just boot the objects
in question over to the C linker instead.
Fixes #59050.
Updates #58619.
Updates #58620.
Updates #58848.
Change-Id: I56382dd305de8dac3841a7a7e664277826061eaa
Reviewed-on: https://go-review.googlesource.com/c/go/+/475375
Reviewed-by: Cherry Mui <[email protected]>
Reviewed-by: Bryan Mills <[email protected]>
Run-TryBot: Than McIntosh <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
(cherry picked from commit 035db07)
Reviewed-on: https://go-review.googlesource.com/c/go/+/476576
|
Closing out this issue, I don't believe there is anything remaining to do here. |
github-project-automation
bot
moved this from All-But-Submitted
to Done
in Go Compiler / Runtime
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes, it reproduce with 1.19, 1.20 and gotip.
What operating system and processor architecture are you using (
go env)?What did you do?
I'm running coverage analysis via Bazel, with CGO enabled, and LLVM 12 configured as llvm toolchain.
rules_go is the latest release, v0.38.1.
What did you expect to see?
Coverage analysis work as it did in Go 1.18.
What did you see instead?
Loadelf reporting symbols:
It looks like the coverage generation using generated symbols named
__covrec_*was added in LLVM 11 so I'd expect the same to happen on all versions after 11. This hasn't been tested.If I disable CGO the coverage works.
The text was updated successfully, but these errors were encountered: