IRC channel logs

<damo22>moment of truth, building latest packages

***Server sets mode: +nt

<damo22> https://www.youtube.com/watch?v=YIMzjNm0z9M

<damo22>Pellescours: you probably need to write some .S asm for x86_64

<damo22>to port the i386 to x86_64

<damo22>some of the code is hardware specific iiuc

<damo22>----

<damo22>i reverted a patch that i thought was unneccessary but turns out its essential, rebuilding

<damo22>wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100) (using DMA)

<damo22>oh crap i applied the wrong patch and broke the rumpdisk binary linkage again

<damo22>rumpdisk.static builds ootb

<damo22>:D

<damo22>rumpdisk: http://paste.debian.net/plain/1137031

<wleslie>well done

<damo22>hmm the dynamic version does not work

<gnu_srs1> damo22: Congrats :)

<damo22>gnu_srs1: thanks

<damo22>i think there is still some work to be done to get it all merged

<janneke>Pellescours: that's great; i have some knowledge and it certainly can't hurt to just show what your problem is

<Pellescours>I put my work here : https://github.com/etienne02/gnumach/tree/master-x86_64

<Pellescours>I have problem of relocations

<youpi>Pellescours: take care, there are two 64bit port branches

<youpi>we should first need to merge them

<youpi>before working on top of it

<youpi>otherwise you run the risk of working on issues that have already be solved in the other branch

<youpi>ah, it seems the port-64 branch is merged into master-x86_64

<youpi>so it'd be fine

<janneke>youpi: thanks for fixing and applying my patch -- i found the "-link" in rpath-link still uncommited in my git

<youpi>Pellescours: take a lot of care when backporting things, see the update I made in master-x86_64

<youpi>Pellescours: also, you do not appear in the FSF copyright holder record

<youpi>you need to assign copyright before we can apply significant patches

<youpi>Pellescours: I don't think we'll want to use a PIC/PIT on x86_64

<youpi>and rather use the APIC, see the existing work about that

<youpi>so I'd say first better fix the APIC support on 32bit

<youpi>otherwise you'll have to make *both* 64bit work and APIC work at the same time

<youpi>which is doomed to desperate bugs

<youpi>better start from something that works than having to fix everything at the same time

<youpi>-extern unsigned long cr3;

<youpi>+extern unsigned int cr3;

<youpi>that doesn't make sense, it really is a long

<youpi>since it has to contain a poniter

<Pellescours>okay thank you

<Pellescours>tail /var/log/apache2/error_www.log

<Pellescours>fail

<youpi>Pellescours: there is no need to make 64bit variants for get_cr0 etc.

<youpi>mov will automatically use the proper size according to the register

<youpi>and the register will be chosen according to the integer size

<youpi>and unsigned long happens to be the proper size

<youpi>Pellescours: you don't want to change the ldscript, compared to what is already there

<youpi>it already is a proper script for an AT build

<youpi>also, don't revert spl.S

<youpi>you have a borken version right now, which is 32bit

<youpi>I don't think we want to rewrite i386/i386 into x86_64/x86_64. At best what we'd want to do is create a common x86 directory where to put these shared files

<youpi>in general, do not modify what you do not need modify if there is no good reason

<youpi>otherwise it'll be hard to merge back your changes in

<youpi>see the current master-x86_64 branch for the x86_64/ldscript and x86_64/locore.S files, I don't think you need more changes there

<youpi>concerning 64bit on non-xen platforms, in my view the roadmap is three-fold: APIC, bootstrap from grub, userland RPCs

<youpi>as mentioned above, APIC should be worked on in 32bit mode, to start from something that works

<youpi>userland RPCs should be worked on in Xen, to start from something that works too

<youpi>bootstrap from grub has to be done like you did, though

<youpi>the point there is to get c_boot_entry() to start

<youpi>I don't know if grub can boot directly into 64bit mode on legacy BIOS, that needs to be checked

<youpi>possibly with EIF BIOS it can boot directly into 64bit mode, that would need to be implemented too

<youpi>s/EIF/EFI

<Pellescours>for what I know in BIOS you boot from 32bit mode and have to change into 64 bit mode

<youpi>grub isn't able to load a 64bit binary on BIOS ? ew.

<youpi>btw, please learn about the 64bit ABI

<youpi>parameters are *not* passed the same way

<youpi>I'm pushing a fixed kdasm.S

<youpi>I'd say first try to implement 64bit EFI boot

<youpi>that'll be one step less to achieve before having something that works

<JohnDVD>what is the progress of the hurd-kernel? Can it replace linux / linux-libre one day?

<youpi>JohnDVD: please read the faq mentioned in the topic

<youpi>Pellescours: in boothdr.S, you need to use __rela_iplt_start/end

<Pellescours>okay

<youpi>Pellescours: concerning the relocation problem, I'd say just comment out the culprit code for now (boot_gdt - KERNELBASE), and you'll figure what to do about it later

<Pellescours>youpi: there is a problem in your kdasm.S

<Pellescours>#define count %dx // B_ARG2

<Pellescours>is incompatible with

<Pellescours>movqcount, %rcx

<Pellescours>movq count, %rcx

<youpi>see the update I pushed later on

<Pellescours>perfect

<Pellescours>youpi: I pushed on my github master branch 2 commit to allow build on x86_64. I have the same problems of linkage as before. They relate on the i386/i386at/model_dep.c file

IRC channel logs

2020-03-28.log