.dynstrand similar sections at this time (which are loadable if you follow program headers) so I went with section headers. But I guess I could filter on the addresses. I'll do that.
Intel lost some 20gb of internal documentation and source code of their CPU platforms. Might be interesting for some of you ;)
I don't think so, at least not yet. The problem is that every allocation must be freed to the allocator it was allocated from. Crate-local allocators conflict with this because you can pass ownership of allocations across crate boundaries (e.g. passing a
Box by value to a function of another crate).
To safely use multiple allocators, we need a mechanism to keep track of the origin allocator for every allocation. The "allocators" working group is trying to solve this problem by adding an additional generic type parameter to all collections types of the standard library that specfies the allocator. This way, you could write generic functions that work with multiple allocators and the compiler would automatically use the correct allocator for deallocations. You still have to be explicit about this, as far as I know there is no proposal to change the allocator default on the crate level.
Thanks for the info! One way I could come up is compiling a set of dependency as a static library and link into main binary across FFI. This will probably raise a lot of other problems in the future.
Actually I’m working on a user level self-paging mechanism for my microkernel based OS. it makes the allocator design more complicated than normal kernel allocator. The whole memory bookkeeping code are mixed together. And if I want to use alloc crate’s data structure, I have to deal with circular dependency of all these things. This is a big headache…
I switched from
cargo xbuild to
cargo build with the
[unstable] build-std = ["core", "compiler_builtins", "alloc"] in
.cargo/config, and I can
cargo build and
cargo run just fine. However,
cargo test complains about duplicate lang items, such as:
error: duplicate lang item in crate `core` (which `rustc_std_workspace_core` depends on): `bool`. | = note: the lang item is first defined in crate `core` (which `cfg_if` depends on) = note: first definition in `core` loaded from /home/sam/Dev/NSVK/nsvk/target/x86_64-bare/debug/deps/libcore-d89c55700f35e4c6.rmeta = note: second definition in `core` loaded from /home/sam/Dev/NSVK/nsvk/target/x86_64-bare/debug/deps/libcore-e587b9194b87d682.rmeta
Any idea where to look at?
0xb8000is the default physical address for the VGA text buffer. The address
0xa000is used for some pixel-based framebuffer modes with small resolutions. Currently the bootloader identity-maps these buffers so that they have the same address in the virtual address space. However, I'm currently working on a rewrite of the bootloader that will allow placing these buffers at arbitrary virtual addresses through configuration
Superleaf1995i've been listening on port 5 but nothing comes
can I use
bootloader to build a higher half kernel? I follow the README and configured the crate like this:
[package.metadata.bootloader] kernel-stack-address = "0xFFFFFF8000000000" kernel-stack-size = 128 physical-memory-offset = "0xFFFF800000000000" boot-info-address = "0xFFFFFFFF80000000"
The kernel successfully setup page table and jump to higher half. But the symbols are not linked to higher half. I tried to write a linker script and set it in cargo config file, but the kernel won’t boot. I saw the documentation about higher half is not finished. Is this feature not finished or my config is wrong?
The error message from the bootloader is not very useful unfortunately, as it does not contain the virtual page address that was already mapped (the contained address in the physical address of the frame, which is not very useful). I try to fix this in the upcoming rewrite.
My guess is that your kernel might have overlapping segments, so that the bootloader tries to map the same page twice. Could you run
objdump -p on your kernel ELF executable so that we can see whether this is the case?
ah you are right. the segments are overlapping
Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000001000 0xffff800000000000 0xffff800000000000 0x0000000000002321 0x0000000000002321 R 0x1000 LOAD 0x0000000000003330 0xffff800000002330 0xffff800000002330 0x0000000000016250 0x0000000000016250 R E 0x1000 LOAD 0x0000000000019580 0xffff800000018580 0xffff800000018580 0x0000000000000050 0x0000000000000050 RW 0x1000 LOAD 0x00000000000195d0 0xffff8000000185d0 0xffff8000000185d0 0x0000000000000f50 0x0000000000000f50 RW 0x1000 GNU_RELRO 0x0000000000019580 0xffff800000018580 0xffff800000018580 0x0000000000000050 0x0000000000000a80 R 0x1 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 0x0
I just looked through the default linker script on my machine (run
ld --verbose) and it appears that the section alignment is done via:
ALIGN(CONSTANT (MAXPAGESIZE)) + (. & (CONSTANT (MAXPAGESIZE) - 1))
The part after the
+ should not be needed, it is just an optimization to allow the sections to be placed directly adjacent in the executable (no empty padding bytes between sections).
-C link-arg="--image-base=0xffff800000000000”. But this is much easier than a custom linker script...