__sync_val_compare_and_swap_ linker error #58500
Comments
estebank
added
the
A-linkage
sanxiyn
added
the
O-Arm
jonas-schievink
added
C-bug
|
I believe I think that means even though this error appears at the linker stage, it's not the linker's fault: the compiler should have substituted the relevant inline code already. |
|
Hm; maybe things aren't that simple. LLVM's behavior seems to be arch-specific: We probably can't conclude that this linker error means the same thing on different platforms. While on x86_64 I expect some inline assembly, it looks like some other platforms may emit an actual separate function or even a library call. |
|
Unlike with #56798, I'd expect no such function call to be generated at all in this case (since the code apparently doesn't make use of atomics). @lights0123 can you perhaps provide instructions for reproducing this issue, preferably with minimized code? |
|
I hit this case when building for ARMv4T (using |
jonas-schievink
added
the
E-needs-mcve
|
@Lokathor I fixed it with a quick fix: https://github.com/lights0123/ndless-handler/blob/3f3f3150860926e0622e394dbaeea32865c7663f/src/lib.rs#L62 Adding |
|
I had some dummy impls, but |
jonas-schievink
removed
the
E-needs-mcve
spastorino
added
I-prioritize
|
Tagged as |
|
I think the correct solution is to add: "max-atomic-width": 0to the target JSON. I don't think there's any bug here. If a target doesn't have native support for atomics then that either needs to be specified in the target JSON as above or implementations for the |
|
@ollie27 that appeared to fix it (Although I'll probably stick with I would say that this should be documented somewhere, but there doesn't seem to be a place where the target.json format is really documented other than the compiler docs. There's a single paragraph in the embedonomicon, but everything about target.json files is really is community blog posts. Should this be documented somewhere? |
|
If there is no place to document it then we need to make a place and then document it there. |
|
I'll send a PR probably tomorrow to add a new page to the embedonomicon all about them, as there's no other place really about it. |
|
Can someone check that my notes about atomics are correct in rust-embedded/embedonomicon#67? I believe that most of what I said is true, but I'm not sure if manually implementing these functions is correct:
|
It can actually go up to 128. |
|
So if I have 1 core, and no threads, and no native atomics, but I do have interrupts, then I guess I'm the last bullet point? perhaps that case needs to be made more explicit |
|
@Lokathor i just made that up (although the phil-opp blog does use atomic for single-core interrupts), but it does makes sense. A non-atomic increment looks like:
If you have an interrupt in there, you might get:
You could manually implement atomic instructions though to disable interrupts, do the operation, and then re-enable them. |
@Lokathor bolded "no interrupts" |
|
right, your list has bullet 1 with "no interrupts" required, but i do have interrupts, so i guess that makes me fall to the "otherwise bullet 4" case. |
|
Yep, I just took your suggestion to make it more obvious. |
67: Add notes about creating a custom target r=therealprof a=lights0123 As we were discussing rust-lang/rust#58500, I realized that there is nowhere other than community blogs that actually discusses *how* to create a new target. This adds new documentation about creating custom targets and common pitfalls that you may encounter. Co-authored-by: lights0123 <[email protected]> Co-authored-by: Ben Schattinger <[email protected]>
|
🎉 that page is now live at https://rust-embedded.github.io/embedonomicon/custom-target.html! I'll consider this fixed (although it's not live at the main embedonomicon page yet, I'm hoping that'll get automatically pushed). |
nightly-2019-02-06does not cause this error, but one revision later,nightly-2019-02-07, does. I'm targeting an embedded device that uses newlib and a custom gcc build. However, February 2nd, 2019's build of nightly Rust causes a link-time error, referring to__sync_val_compare_and_swap_1,__sync_val_compare_and_swap_2, and__sync_val_compare_and_swap_4. No atomic types are being used by my project. This seems similar to #56798.Here's my custom target.json, and a log of the error:
The text was updated successfully, but these errors were encountered: