IRC channel logs
2025-12-30.log
back to list of logs
<paculino>A friend had that issue and it ended up being a hardware issue; somehow one of the ram sticks got messed up one day <damo22>no, this is developing the kernel <paculino>Oh, the kernel can't, not a individual machine. I misunderstood <damo22>yeah sorry, this is also the development channel <paculino>I know; it makes more sense than the mailing list alone being for that <damo22>so my problem is twofold on hurd64: if i store apboot in .text section, that is 64 bit addressable, but the relative jmps cannot be assembled in .code32 <damo22>or maybe they can but the relocation fails <damo22>this is because the linker is unaware i will be manually copying the code to a low segment at rjuntime <youpi>if there is a relocation, it's not actually a relative jump <youpi>relative jump precisely allow to avoid relocations :) <damo22>alternatively, if i put apboot in .boot.text section, that is 32 bit addressable, so the relocs just work TM, but then i cannot modify the address in C code <damo22>how do i write a relative "ljmp" instruction? i need to reload the gdt <damo22>i think the label gets relocated <damo22>maybe i can avoid the reloc if i use "retf" instruction? <damo22>but i dont know if that reloads the gdt in protected mode <youpi>a ljmp probably doesn't support relative adressing <youpi>but you can probably first load the address in a register, and ljmp to it <youpi>and lea can then do the relative computation <youpi>alternatively, you can call $1f ;1: pop %eax, and then add the difference between that 1: and your ljmp target label <damo22>create a far pointer on the stack and do a far jmp? <youpi>you can do that too, but it'll be simpler to just put the poniter in a register <youpi>about arm vs x86, studying x86 is not useless. It's still there for a long time, and all these addressing questions also happen just the same on arm <damo22>now i think i fixed it, but i cant write to the address from C code, but gdb can <damo22>i get a kernel page fault writing to it <almuhs>if you use paging, this must be in PAE mode <almuhs>Before 64-bit paging can be set up, 32-bit paging needs to be disabled (this can be skipped if paging was never set up in the first place). <almuhs>64-bit paging uses PAE paging with an extra level, which includes (in order of distance from the root): <almuhs>and 64-bit requires loading a new GDT <almuhs>but the jump to long mode is made from protected mode <almuhs>so you need keep the current code to jump to protected mode, and add a new jump to long mode at the end <damo22>almuhs: boothdr.S already has code to jump into long mode, my problem is the relocations for the far jumps to reload gdt <damo22>because APs must boot from real mode using sipi vector <damo22>so they start from a manually copied code block <damo22>it would be much much easier if we just choose a hardcoded address <damo22>otherwise i have to hack the code and make the code seg and data seg the same so the code can be overwritten at runtime <damo22>because you cannot reload gdt using relative jumps <almuhs>yes, we can hardcode the address in the 64-bit case <damo22>its literally just choosing a number like 0x10000 and adding it as a constant offset to the addresses we need <damo22>we just have to avoid stuff in ram on x86 <almuhs>yes, but we need check that the new address is not busy <damo22>there must be a chunk of low memory that nobody uses on x86 <almuhs>anyway is a good idea. We only need to find the correct offset <almuhs>be careful to don't touch BIOS configuration data <damo22>the page tables for 64 bit setup is quite a few pages <damo22>and they all have to be 32 bit addressable <almuhs>keep the dynamic address for protected mode, and set a hardcoded address for long modr <damo22>no, the first real mode address is the problematic one <damo22>i want to avoid patching the code at runtime for the offset <damo22>it weakens the security by making the entire section writable <almuhs>then we have to find a good static address valid both for 32-bit and 64-bit <damo22>i think we just define a MEMORY section in ldscript and put it exactly there <almuhs>in segmentation, the address after 0xffff... are considered virtual address <almuhs>wait, maybe this is not the limit <almuhs>i don't remember exactly which is the address <almuhs>but you must consider this case anyway <almuhs>you only can access to address higher than this with paging <almuhs>i go to sleep. i will read you tomorrow <damo22>yeah but we cant use higher than 0xA0000 <damo22>ldscript does not seem to like adding a section earlier than _START without the entrypoint in it <damo22>i just want to load a read only section at 0x11000 <damo22>but not execute from it initially <damo22>ok i got that to work but now it cant find the multiboot header <damo22>in the first 8K of the executable and 8 byte aligned, apparently <youpi>damo22: I have checked the intel manual, apparently indeed a far jump can't be done with a register <youpi>so, indeed, ljmpl $KERNEL_CS, %eax can't work <youpi>but ljmpl *(%esp) should work indeed <youpi>by putting $KERNEL_CS,%eax on the stack <youpi>and leal can be used to get the adress through relative addressing <youpi>before putting it on the stack <damo22>ive rejigged the ldscript to install the multiboot header in realmode segment and apboot16 section at hardcoded offset 0x11000 that does nothing until AP bringup <damo22>now im dealing with a double fault again probably from something ive missed <damo22>lol assert(apboot != NULL) double faults <damo22>=> 0xffffffff81025df9 <mp_desc_init+9>: cmpq $0x0,0x7efeb1ff(%rip) # 0x11000 <apboot> <damo22>fixed that issue, now biosmem_free_usable() traps <youpi>did you exclude that section from the allocator? <youpi>otherwise you'll have issues as soon as it gets allocated etc.