Fix building with new rust-nightly.#561
Conversation
|
jarovo
force-pushed
the
main
branch
3 times, most recently
from
951729a to
fc8b4cc
Compare
This workarounds a problem with clippy:
```
Error: --> tests/test_kernels/stack_address/src/bin/basic_boot.rs:27:1
|
27 | / fn panic(info: &core::panic::PanicInfo) -> ! {
28 | | use core::fmt::Write;
29 | |
30 | | let _ = writeln!(test_kernel_stack_address::serial(), "PANIC: {info}");
31 | | exit_qemu(QemuExitCode::Failed);
32 | | }
| |_^
|
= note: the lang item is first defined in crate `std` (which `bitflags` depends on)
= note: first definition in `std` loaded from /home/runner/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-dd28cbf307893515.rmeta
= note: second definition in the local crate (`basic_boot`)
```
Yes, it seems like got fixed before me noticing it. May I ask you to leave a comment on the idea of making the |
|
It's an interesting idea, but one that makes me a bit nervous. rustc isn't always very good with stack usage and this change would get us more than halfway to the limit. I've seen the compiler duplicate individual stack variables when they're being moved around (and double the required stack memory) before and if that were to happen here that'd exceed the stack size. I'd hope it wouldn't do that here, but I'd feel more comfortable if we didn't leave this up to chance. |
2 participants
after bumping the tempfile to use new deps, there was this linker issue to be fixed:
To address this I made disk_buffer a stack variable instead of static variable because the now large
.textregion pushed the.bssso much that it didn't fit to the 16bit address range ( the.textprecedes the.bssin thestage-2-link.ldfile). Another advantage is that this allowed me to remove the unsafe block. I think I was getting some memory corruption when dealing with the references to the static mem region.IIRC After moving the
disk_bufferto the stack the some of the testsBIOS bootand then nothing was happening. After changing the ESP to0x00080000all the tests are passing. Only thelarge_ramdisktest sometimes fails. It seems to be flaky - many times it passes.