IRC channel logs

<damo22>azert: I dont think userspace usually uses MSRs

<damo22>and the kernel gs base msr most likely not

<damo22>youpi1: i mean -KERNELBASE segmentation

<damo22>it seems the kernel is loaded at 0xC1000000 but the code is relative to 0x1000000

<damo22>in i386 version

<damo22>CS =0008 40000000 ffffffff 00c09b00 DPL=0 CS32 [-RA]

<damo22>this call actually lands at 0x81018400

<damo22>the gdt must be ruinde

<damo22>ruined

<damo22>but if the code is actually loaded at 0xc100000 why do we need to change the base address of segmentation?

<damo22>c1018400 <cpu_ap_main>:

<damo22>c1018400: 55 push %ebp

<damo22>ok i figured it out

<damo22>youpi1: ive done a lot of work on smp64 this week but its not ready

<damo22>it page faults on 64 bit smp but displays a console so we can continue work on it

<damo22>maybe i should tidy up what ive done, test it for regressions and submit this

<damo22>what is in master does not even compile on 64 bit with smp

<damo22>ok i mailed in a patchset

<damo22>why would this instruction fail on bsp? ffffffff81032e27: 36 48 3b 14 cd 40 00 cmp %ss:-0x7ef2ffc0(,%rcx,8),%rdx

<damo22>ffffffff81032e27: 36 48 3b 14 cd 40 00 0d 81 cmp %ss:-0x7ef2ffc0(,%rcx,8),%rdx

<damo22>the SS segment is set to be a data segment, doesnt it need to be code?

<damo22>CS =0008 0000000000000000 00000000 00209b00 DPL=0 CS64 [-RA]

<damo22>SS =0010 0000000000000000 00000000 00209300 DPL=0 DS [-WA]

<damo22>cmp cannot encode 64-bit immediates

<damo22>ah

<gfleury>hi

<gfleury>damo22: Commit fdfca0e86009c5a7b188fa39e939de800a73391d broke smp boot

<damo22>i agree

<damo22>but thats separate to my work

<damo22>64 bit smp now compiles :D

<damo22>there are a lot of cmpq instructions in x86_64/locore.S that try to use 64 bit immediates

<damo22>but i think they are all broken

<gfleury>I know. you can a least start with a commit that work for i386

<damo22>yeah, i will retest with that commit reverted

<rrq>hmm I only had one small patch for x86_64/locore.S (changing "CPU_NUMBER_NO_GS(%ecx)" to be "CPU_NUMBER_NO_GS(%rcx)" )

<damo22>rrq: see my patch series

<damo22>gfleury: with fdfca0e86 reverted, i386 smp works again with my patch series as well

<damo22>although it throws a warning about the kmsg thing

<rrq>ok.. I may confuse git repo.. which do you use?

<damo22>rrq: i mailed in a patch series to the mailing list of 11 patches for gnumach

<damo22>rrq: but you can try this equivalently https://git.zammit.org/gnumach-sv.git/log/?h=smp64

<rrq>thanks. sorry.. I'm a bit slow on the take-up, and actually not on the list yet

<rrq>(cloned)

<damo22>its on branch smp64

<gfleury>damo22: that's great

<damo22>somehow the sign extension is not working on a cmpq instruction CR2=00000007810d6ab8

<damo22>because it is not an immediate but a memory location

<damo22>but its abusing the offset(, reg, width) syntax by attempting to put a 64 bit address in offset

<damo22>how do you actually do a cmpq of a label + reg*8 with a register?

<rrq>damo22: your branch builds fine for me

<rrq>I used ../configure --prefix=/opt/ralph/hurd --build=x86_64 --host=x86_64 --enable-kdb --enable-ncpus=8

<rrq>(and have "mig" built)

<rrq>though I'm still a newbie at x86 64bit assembler

<rrq>(well, I've done a fair amount 64bit fasm, but that doesn't count here)

<damo22>i am fixing the 64 bit addressing on some instructions

<damo22>ffffffff81032e27: 36 48 3b 14 cd 40 00 0d 81 cmp %ss:-0x7ef2ffc0(,%rcx,8),%rdx

<damo22>this kind of thing does not sign extend

<rrq>how about using "0xeef2ffc0" instead of "-0x7ef2ffc0" ?

<rrq>no 0xfef2ffc0

<rrq>mmm or I guess it should be the 2-complement rather

<rrq>0x810b0040

<damo22>that is what it is, but it doesnt seem to work

<damo22>offset(, reg, width) does not seem to sign extend the offset

<damo22>at least not to 64 bits

<damo22>i am happy to be proven wrong

<damo22> 0xffffffff81032bf1 <+6>: mov %gs:0xc,%ecx

<damo22> 0xffffffff81032bf9 <+14>: and $0xfffffffffffff000,%rdx

<damo22> 0xffffffff81032c00 <+21>: mov $0xffffffff810d0040,%rdi

<damo22>=> 0xffffffff81032c07 <+28>: add 0x0(,%rcx,8),%rdi

<damo22>it is stuck here

<damo22>oh that is trying to access memory at 0x0

<damo22>how do i write rdi = rdi + 8*rcx?

<rrq>right, the instruction is "3b" isn't it... CMP r64, r/m64

<rrq>no, I don't know enough.. sorry

<azert>damo22: try with "lea"

<azert>leaq (%rdi,%rcx,8), %rdi

<azert>in sane syntax: lea rdi, [rdi + rcx*8]

<nikolar>q is optional, so `lea (%rdi,%rcx,8), %rdi` works

<nikolar>you have a 64 bit register as the destination

<azert>what's really insane in the at&t syntax is that they inverted src and dst operands at a time where most people were used to memory/accumulator architecture where the register was part of the opcode

<azert>and x86 wasn't fully orthogonal at that time either

<azert>eax is the accumulator, ecx the index, edx for 64 bit, edi and esi for pointers etc.

<nikolar>i don't think it's that insane considering the gcc history but ok

<azert>indeed, PDP-11 culture wearing x86 clothes

<nikolar>more like vax, but sure

<nikolar>pdp-11 assembly doesn't look like at&t

<azert>did you guy followed the recent UNIX-V4 resurrection? I was surprised most of it written in asm https://github.com/Equilateral-AI/UnixV4-Resurrection/tree/main/usr/source/s1

<nikolar>yea, i think only after v4 they started the c rewrite

<nikolar>iirc, c was actuatlly first implemented on v4

<azert>a few utilities are in c

<nikolar>yea

<gnucode>ok, I'm going to try to type up a q4 qoth.

<sneek>gnucode, you have 1 message!

<sneek>gnucode, nexussfan says: Live hurd may be possible, but probably not on USB because there's really bad support for usb on hurd

<gnucode>and my emacs is not currently starting. I guess I'm using vim today, sorry rms

<gnucode>I feel like I should also mention the ext2fs new journal.

<nexussfan>That would be nice.

<gnucode>I'm about to mail it in.

<nexussfan>HOST_NAME_MAX isn't defined on Hurd systems it seems

<nexussfan>What is the real host name limit then? or is there a different way instead to get it?

IRC channel logs

2026-01-02.log