IRC channel logs


back to list of logs

<damo22>moment of truth, building latest packages
***Server sets mode: +nt
<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>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
<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 :
<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
<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
<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
<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>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