-
Notifications
You must be signed in to change notification settings - Fork 94
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
Lazy
panics under bare metal environment
#154
Comments
This seems to me like a bug. I'm going to investigate this today. |
I've gone of the implementation quite carefully. Is there anything unusual about the platform you're running on? Perhaps unusual or non-existent support for atomics, or a CPU that starts with SMP enabled by default? |
Here is my qemu command
The elf is compiled with the target
I don't think there is there's anything unusual with the configuration. They are written to |
Is it possible that you have something like an interrupt handler being invoked at an unexpected time? |
Just for debugging, I've changed the interrupt handler to
If the interrupt is invoked, it should end up in the dead-loop. Yet interrupt is not triggered, the code panics still. |
(Disclaimer: I don't know what linker scripts are being used or what assembly is being generated, so I can only speak to some guesses.) First, one of the differences between
Second, rustc does not automatically adjust
As mentioned at the outset, I'm not certain that misalignment is the cause of the problem, but the fact is that I could not reproduce this problem in an environment3 where
BTW, probably not related to this problem, but I guess that if you have not recompiled the standard library with this flag, the standard library compiled with the c target-feature will be linked, so the binary will have a mix of compressed parts and non-compressed parts. Footnotes
|
Thank you so much for this detailed explanation. The code was compiled with
When I changed it to
the problem was solved. Some quirk with the linker! Again, thank you so much for dealing with this bug that was caused by myself after all! |
To be clear: I think "standard library" in my comment was misleading (I also meant core and alloc), but even with |
Oh ok great! That actually answers why I was having some strange issues with core libs when I tries to run the binary on the real chip. Again thanks for the clarification😄 |
Woo, good to hear this is solved! I was worried this might have been a soundness issue in Thanks @taiki-e for providing your knowledge! |
Hi,
I was trying to replace
lazy_static!
withLazy
. While it works fine under normal environment (tried with rust playground), when I tried running it in bare metal (qemu rv64gc no compression), code panics with message: "Lazy instance has previously been poisoned" spin-0.9.8/src/lazy.rs: 100:21.Here is the code segment
In my understanding,
Lazy
should have the same behavior withlazy_static
, or are they actually different and shouldn't be mix used? I'm using it primarily for initializing peripherals like uart and stuff, if there are better alternatives, please tell me.Thank you!
The text was updated successfully, but these errors were encountered: