Also where is the correct place to add -finitarray thing, maybe should be in gcc config for arches?
I currently add it in GCC configure command parameters. It should be fine to add it for all architectures except gcc2 after adjusting boot loader and kernel linker scripts.
1 Like
Yes I think it would be better to have in gcc setup, so if we plan to change anything in gcc arch maybe we should add them.
Yes I am aware of that part. I just want to make sure gcc never uses ctors anymore.
You should be able to do a full build now if you comment out:
if [ -z "$secondaryArchSuffix" ]; then
pythonModuleEnabled=true
fi
in haikuports/dev-libs/libxml2/libxml2-2.9.12.recipe
Then with the efi.sh drive part changed to:
-drive file=fat:rw:disk,format=raw \
-drive file=haiku-bootstrap.image
You should get the same kind of log in console.
6 Likes
Found the bad pheader problem. We define it as PT_STACK header type, and in linker it is .note.GNU-stack. It marks executable permissions on the stack, which we should hopefully never want.
It was enabled due to a bad flag in our gcc-config which has been fixed in this commt: https://git.haiku-os.org/buildtools/log/?qt=range&q=5cccbfddbae2+^dcd0415ded94
If anyone is building, you have to rebuild the compiler and recompile. Since I also added the initarray flag by default (as a PR), you might want to wait until that has been sorted out: https://review.haiku-os.org/c/buildtools/+/4408
So where does this leaves us:
load kernel kernel_arm64...
arch_elf_relocate_rela: unhandled relocation type 1026
relocating kernel failed: 80000010!
Now we need to check what this relocation type is. If it should be there, we should handle it. If not figure out why it is there and remove it, either in gcc config, but more likely in the linker script.
9 Likes
I also became somewhat lazy so created a script for EFI: disk/startup.nsh:
fs0:haiku_loader.efi
Now I only need to press a key at the countdown.
8 Likes
The relocation type is R_AARCH64_JUMP_SLOT and we need to add handling of it and other types in src/system/kernel/arch/arm64/arch_elf.cpp.
The good thing is that there is already work done in previous efforts to document what relocation we need and what they should do: haiku/arch_elf.h at 8f16317a5b6db5c672f331814273e5857555020f · haiku/haiku · GitHub
3 Likes
You can look at riscv64 version for reference: https://git.haiku-os.org/haiku/log/src/system/kernel/arch/riscv64/arch_elf.cpp.
4 Likes
I already did look at both EFI and kernel relocations, but it’s hard to know if the intentions is different on different platforms. For instance, do not look at ARM relocation code 
I’m to tired to start anything today though.
It’s a good thing there is plenty of docs here: GitHub - ARM-software/abi-aa: Application Binary Interface for the Arm® Architecture including ‘ELF for the Arm 64-bit Architecture’.
5 Likes
Implemented (copied from x86_64) the three relocation cases needed:
load kernel kernel_arm64...
maximum boot loader heap usage: 382104, currently used: 372976
kernel:
text: 0xffffffff80000000, 0x190000
data: 0xffffffff80190000, 0x7a000
entry: 0xffffffff80080168
Kernel stack at 0xffff0000023d4000
System provided memory map:
0x40000000-0x45cce000 0x0 0x7 0x8
0x45cce000-0x482a1000 0x0 0x2 0x8
0x482a1000-0x483c0000 0x0 0x1 0x8
0x483c0000-0x48420000 0x0 0x9 0x8
0x48420000-0x48430000 0x0 0x2 0x8
0x48430000-0x48460000 0x0 0x9 0x8
0x48460000-0x484e0000 0x0 0x5 0x8000000000000008
0x484e0000-0x486a0000 0x0 0x6 0x8000000000000008
0x486a0000-0x48750000 0x0 0x5 0x8000000000000008
0x48750000-0x490d9000 0x0 0x7 0x8
0x490d9000-0x4a7fb000 0x0 0x4 0x8
0x4a7fb000-0x4a827000 0x0 0x7 0x8
0x4a827000-0x4a84f000 0x0 0x4 0x8
0x4a84f000-0x4a856000 0x0 0x7 0x8
0x4a856000-0x4b644000 0x0 0x4 0x8
0x4b644000-0x4b861000 0x0 0x7 0x8
0x4b861000-0x4bc20000 0x0 0x3 0x8
0x4bc20000-0x4bdb0000 0x0 0x5 0x8000000000000008
0x4bdb0000-0x4c000000 0x0 0x6 0x8000000000000008
0x4c000000-0x4c01f000 0x0 0x7 0x8
0x4c01f000-0x4c020000 0x0 0x4 0x8
0x4c020000-0x4f76e000 0x0 0x7 0x8
0x4f76e000-0x4f78f000 0x0 0x4 0x8
0x4f78f000-0x4f7c4000 0x0 0x3 0x8
0x4f7c4000-0x4feec000 0x0 0x4 0x8
0x4feec000-0x4fef0000 0x0 0x3 0x8
0x4fef0000-0x4fff1000 0x0 0x4 0x8
0x4fff1000-0x4fffb000 0x0 0x3 0x8
0x4fffb000-0x50000000 0x0 0x4 0x8
0x4000000-0x8000000 0x0 0xb 0x8000000000000001
0x9010000-0x9011000 0x0 0xb 0x8000000000000001
Calling ExitBootServices. So long, EFI!
It might be time to look at memory mapping soon…
9 Likes
There is a previous attempt at the ARM64 paging attempt here that you may be able to reuse in part: haiku-jarek/src/system/kernel/arch/aarch64 at master · korli/haiku-jarek · GitHub
6 Likes
What is a status of that code? What is actually working?
2 Likes
I don’t know. The person who wrote it submitted a few parts to Gerrit, but they never posted screenshots or anything like that. It looks like at one point it may have gotten to the desktop based on the commit messages, but it was not in a state to be merged, nobody took up the task of cleaning it up, and it’s now bitrotted.
2 Likes
It seems to use boot loader approach similar to my haiku_loader.riscv: haiku-jarek/src/system/boot/platform/qemu-virt at master · korli/haiku-jarek · GitHub.
3 Likes
It also implemented boot loader abstraction of virtual memory mapping, including x86. Definitely worth to investigate.
3 Likes
It also have some generic kernel improvements: vm_page.cpp: use wait condition for page scrubbing · korli/haiku-jarek@d11894d · GitHub.
2 Likes
A few of those kernel changes I merged or implemented an equivalent since then, I think, so those would need to be checked over carefully. The bootloader stuff I did not touch at all.
2 Likes
Interesting:
2 Likes