Fix building with new rust-nightly. - #561
Conversation
|
Sorry, something went wrong.
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 disk_buffer on stack in stage-2 and setting the base of the stack to 0x00080000 in stage-3 to make it fit the kernel while removing the unsafe section? Perhaps I am missing something, but I think we don't need to preserve the stack between the stages. It is something I would like to check before I un-mark this as Draft. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
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 .text region pushed the .bss so much that it didn't fit to the 16bit address range ( the .text precedes the .bss in the stage-2-link.ld file). 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_buffer to the stack the some of the tests BIOS boot and then nothing was happening. After changing the ESP to 0x00080000 all the tests are passing. Only the large_ramdisk test sometimes fails. It seems to be flaky - many times it passes.