Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Samuel Tardieu
    @samueltardieu
    And you're right that I should use program headers rather than section headers in order to choose what to load. I just didn't want to deal with .dynstr and 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.
    Philipp Oppermann
    @phil-opp
    Ah, I understand what you mean now. You could copy the contents to a separate physical frame on loading. Then you should be able to zero the unused parts again. There's probably also some linker argument to change this behavior.
    Philipp Oppermann
    @phil-opp
    For the program headers I think you can just skip any segments that are not loadable. You shouldn't need to access any string tables this way. For example, with xmas_elf, you can just call the program_iter method and then match on the segment type using get_type.
    Cristian Kubis
    @tsurai
    I just updated rust and suddently cargo build errors with LLVM Error: unsupported x86 interrupt prototype
    did something break with the x86-interrupt calling convention?
    Cristian Kubis
    @tsurai
    nvm, I'm a dumbass :D
    Cristian Kubis
    @tsurai
    Intel lost some 20gb of internal documentation and source code of their CPU platforms. Might be interesting for some of you ;)
    Алексей Пастухов
    @p-alik

    Intel lost some 20gb of internal documentation and source code of their CPU platforms. Might be interesting for some of you ;)

    https://www.zdnet.com/article/intel-investigating-breach-after-20gb-of-internal-documents-leak-online/

    rybot666
    @rybot666
    Intel documents? It's f u z z i n g time
    Vincent Hou
    @vincenthouyi
    Hi everyone! is there someway I can define a crate level allocator so that allocation in that crate will refer to the crate level allocator instead of the global allocator?
    Philipp Oppermann
    @phil-opp

    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.

    Cristian Kubis
    @tsurai
    or you implement a virtual allocator but that would most likely defeat the purpose
    Vincent Hou
    @vincenthouyi

    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…

    Samuel Tardieu
    @samueltardieu

    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?

    Philipp Oppermann
    @phil-opp
    Maybe you're hitting rust-lang/cargo#7359?
    Samuel Tardieu
    @samueltardieu
    Looks like it's exactly that, thanks.
    Cristian Kubis
    @tsurai
    I wonder, which error handling crates are you all using if any?
    Steve Hay
    @stvhay
    hey, where does that memory mapping to 0xb800 come from? is that inherent to VGA somehow?
    i remember from DOS days 0xb800 and 0xa000
    i think there may have been a monochrome thing at 0xb000 also--cant remember
    Philipp Oppermann
    @phil-opp
    0xb8000 is the default physical address for the VGA text buffer. The address 0xa000 is 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
    Steve Hay
    @stvhay
    interesting. look forward to your write up of the bootloader code
    xitan
    @x1tan
    This message was deleted
    3 replies
    Isaac Woods
    @IsaacWoods
    Hi @phil-opp - I made a repository pci_types in rust-osdev, but it's private for some reason and I can't change the visibility. Can you make it public please?
    Philipp Oppermann
    @phil-opp
    Done
    Daniel Ivkin
    @ivkin25
    Hey guys, I am new to Rust and to OSDev. I discovered this so awesome tutorial from a friend. He told me to follow the first edition instead of the second one, because the second one uses too many dependencies in order to implement stuff. First of all, is that true? I want to implement everything by myself, and learn the most. But on the other side, the second one is much more detailed than the first one, and is constantly updated. I would be very happy if you guys could help me decide. Thanks a lot!
    Philipp Oppermann
    @phil-opp
    @ivkin25 I just answered your related email. I won't replicate it here in case other people want give their opinion too. We also have a dedicated channel related to os.phil-opp.com at https://gitter.im/phil-opp/blog_os .
    Harald Hoyer
    @haraldh
    FYI, stabilization of the default alloc error handler merged today is the last step for stable no_std + alloc ... rust-lang/rust@0d37dca
    Andre Richter
    @andre-richter
    Great stuff @haraldh. Its so nice to see std-aware cargo and all the orher bare-metal infrastructure maturing 🎉
    matrixbot
    @matrixbot
    Superleaf1995 does sb16 fire irqs?
    Superleaf1995 i've been listening on port 5 but nothing comes
    Vincent Hou
    @vincenthouyi

    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?

    Philipp Oppermann
    @phil-opp
    The bootloader crate uses the ELF information of the kernel executable to decide where to load the kernel. So if you use a linker script that places the kernel in the higher half, the bootloader should directly load it there (no page table modification from the kernel needed).
    matrixbot
    @matrixbot

    Jacob I'm using a higher half kernel (though not with bootloader), and this is my linker script:

    SECTIONS {
        . = 0xFFFF900000000000;
    }

    With the following line in my .cargo/config target section:

    rustflags = ["-C", "link-arg=-Tlink.x"]
    Vincent Hou
    @vincenthouyi
    image.png
    @phil-opp I’m using a similar linker script like matrixbot’s and it shows this panic
    Philipp Oppermann
    @phil-opp

    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?

    Vincent Hou
    @vincenthouyi
    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
    ah you are right. the segments are overlapping
    Philipp Oppermann
    @phil-opp
    Are you using any additional linker flags? Normally the virtual addresses of the segments should all start on new pages
    It could also be that this alignment is done by the default linker script. In that case, you need to modify your linker script to align the sections
    Philipp Oppermann
    @phil-opp

    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).

    Philipp Oppermann
    @phil-opp
    Instead of using a custom linker script, you can also just override the image base address by passing -C link-arg="--image-base=0xffff800000000000" to rustc. This way, you get the proper alignment by the default linker script and still have a higher-half executable
    Vincent Hou
    @vincenthouyi
    Today I try using another linker script forcing all segments align to page size so that the segments are not overlapping. But now I get another error that the bootloader fails to map the boot info page.
    image.png
    I got the same error using -C link-arg="--image-base=0xffff800000000000”. But this is much easier than a custom linker script...
    I’m not sure if this is my environment. I’m using MacOS to compile and run qemu. But the compiler and linker are shipped along with Rust, I’m not sure if this will cause compatibility problem...
    Vincent Hou
    @vincenthouyi
    It works now! The error is because identity mapping is conflict with kernel mapping. When I set the kernel to a higher place the bootloader can jump to the kernel!
    Philipp Oppermann
    @phil-opp
    Great to hear that!
    Vincent Hou
    @vincenthouyi
    Thank you for your help ;)
    ChipsSpectre
    @ChipsSpectre

    Hey :)
    Which projects of rust osdev would be open to a new contributor?

    I have no experience in OS development so far, but after completing my masters in computer science recently, I want to learn more about this topic and improve my knowledge of rust.