Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: improve error messages for race detector link failures when cross-compiling #49760

Open
DryHumour opened this issue Nov 23, 2021 · 9 comments

Comments

@DryHumour
Copy link

@DryHumour DryHumour commented Nov 23, 2021

Thanks @ALTree . It does look intentional. So @s00500 you'd have to grab the syso from somewhere else, either from the source package or other platform's release package, and place it into GOROOT/src/runtime/race.

It seems the main issue is resolved so we can close this. Thanks.

I'll look into printing a better error.

Originally posted by @cherrymui in #49102 (comment)

@DryHumour
Copy link
Author

@DryHumour DryHumour commented Nov 23, 2021

See also e.g.

#49749
#49102

And thanks in advance @cherrymui !

Loading

@s00500
Copy link

@s00500 s00500 commented Nov 23, 2021

Absolutely fine, already did do so 😃

Loading

@s00500
Copy link

@s00500 s00500 commented Nov 23, 2021

This followup was created to improve the error message though, right?

Loading

@DryHumour
Copy link
Author

@DryHumour DryHumour commented Nov 23, 2021

This followup was created to improve the error message though, right?

Yes, that's right. I lost a day trying to hunt down the root cause of this, thinking it was a problem in our (unconscionably complicated Yocto-ed) toolchain. No-one but myself to blame really, but a better error message would have helped a lot.

Something along the lines of "cross-compiling with race detector requires manual intervention; see http://blahblahblah" :)

In an ideal world, the compiler would quietly download the missing syso for you, but I realise that the risk/reward there is probably small :D

Loading

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Nov 23, 2021

@DryHumour no need to blame yourself. It is indeed a place that needs improvement :)

We could do the detection in the linker, when -race is specified and certain symbols are missing.

I'm thinking if it is better to do it in the go command, where when it does a go build -race, it can error out if runtime/race/race_GOOS_GOARCH.syso does not exist. @bcmills would that be too much for a special case in cmd/go?

Loading

@bcmills
Copy link
Member

@bcmills bcmills commented Nov 23, 2021

I think it would be fine to have a special case, if we're careful about how we factor it.

Perhaps we could put the detection logic in cmd/internal/sys alongside sys.RaceDetectorSupported?

In some sense this is really just a finer-grained answer to that question: “is the race detector supported for this platform in general?” vs. “is the race detector supported for this platform with your installation of the toolchain?”

Loading

@bcmills bcmills changed the title Improve error messages for race detector link failures when cross-compiling cmd/go: improve error messages for race detector link failures when cross-compiling Nov 23, 2021
@bcmills bcmills added this to the Backlog milestone Nov 23, 2021
@bcmills
Copy link
Member

@bcmills bcmills commented Nov 23, 2021

(Perhaps sys.RaceDetectorInstalled?)

Loading

@s00500
Copy link

@s00500 s00500 commented Nov 23, 2021

Without having any idea, my gut feeling also thinks that the go command would be the right place to implement such a warning :-)

Loading

@DryHumour
Copy link
Author

@DryHumour DryHumour commented Nov 23, 2021

Yes, just emitting a message e.g. pointing to a wiki page when cross-compiling and -race is specified would be lovely. Don't even really need to abort the build or do anything fancy with risk for potential unintended consequences: I realise that this is probably something of a corner case for general Go use.

Just pointing in the right direction would help clueless newbs like me who desperately try (and fail) to get their cross-toolchain extld to link cgo with libtsan.... (And, yes, I probably deserved what I got for making the myriad assumptions to even draw that ridiculously flawed conclusion. I feel pretty sheepish in hindsight....) :-)

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants