https://github.com/WebAssembly/threads/issues/144 updated the
WebAssembly threads proposal to make atomic operations on unshared
memories valid. This change updates the feature checking in the linker
accordingly. Production WebAssembly engines have not yet been updated
for this change, so after this change users who accidentally use
atomics with unshared memories will get validation errors at runtime
rather than link errors. This is a small usability regression, but I
think it is warranted because 1) such users are already off the
well-beaten path and 2) as engines do begin to implement this change I
don't want the tools to block experimentation and use of the relaxed
rules.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
So this will effect users who accidentally use -pthread in their cflags but not their ldflags?
If a user uses -pthreadon some object files we have a different way to catch that a link time right? (I think that is more the common problem).
The corresponding semantics change in Chrome can be tracked at https://chromiumdash.appspot.com/commit/895c52ddcb783fed5637cb1e6e31b6fd730872da.
Actually, a better commit to track is https://chromiumdash.appspot.com/commit/e1a9c1e807d3d44e03dc77c69cc2a0303f1d9f38.
Imagine a project that links statically without threads but its as dependency on some autoconf or cmake library that happens to throw in the -pthread... such users would hit this error today so I guess its only new users who do this that would be a runtime rather than link time error after this change.
Do you think this change makes it much hard to go from the error message to figuring out that you need to remove a stray -pthread from some CFLAGS somewhere? At least the current error tells you which object is the problem.
But I guess its only temporary as soon engines will catch up and the error will go away.
In fact they have already caught up. I will update the commit message before landing.