IRC channel logs

<damo22>thank you youpi for fast review, i might work more on smp64 before i go back to work on the 5th

<damo22>youpi: yes, you are right, (%esp) was the problem, it needs to be (%rsp) so it addresses the stack correctly

<damo22>you fixed it

<damo22> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=450cbdd0125cfa5d7bbf9e2a6b6961cc48d29730

<damo22>there is an argument for using a negative offset with that instruction

<damo22>-4 might be enough

<damo22>as you suggested

<youpi>ah, right, using (%rsp) can bring dependencies

<youpi>-4(%rsp) too, but less probable

<damo22>youpi: do you know if "offset(basereg, reg, width)" syntax in AT&T asm actually sign extends the offset up to a 64 bit address if its a negative 32 bit immediate?

<damo22>if it doesnt, then all our CX() calls are broken on 64 bit

<nikolar>that's not a syntax thing, you should check the manuals

<youpi>damo22: I don't know but it should be easy to test with a small program

<Pellescours>I just tried to compile gnumach master (as of now) with ncpus=4 and I get this errror:

<Pellescours>../i386/i386/mp_desc.c:80:1: error: requested alignment ‘1044480’ is not a positive power of 2 80 | uint8_t solid_intstack[NCPUS*INTSTACK_SIZE] __aligned(NCPUS*INTSTACK_SIZE);

<Pellescours>*ncpus=255

<youpi>that looks like an overzealous alignment

<youpi>INTSTACK_SIZE should really be enough

<damo22>hmm yes

<damo22>test.c: Assembler messages:

<damo22>test.c:11: Error: 0x80000000 out range of signed 32bit displacement

<youpi>is a negative value acceptede?

<damo22> asm ("movq 0x80000000(%[rax],%[rbx], 8), %[rcx]"

<damo22> : [rcx] "=r"(rcx)

<damo22> : [rax] "r" (rax),

<damo22> [rbx] "r" (rbx)

<damo22> );

<Pellescours>youpi: if ncpus is odd, the build fails, if its even (ex: 256) it works

<youpi>that'd rather be power-of-two requirement

<youpi>try 6 for instance

<youpi>anyway, please test without NCPUS* and send a patch if successful

<damo22>Pellescours: maybe remove the "NCPUS *" in the alignment

<damo22>its not easy to test the sign extend because the memory address does not resolve in userspace

<youpi>you can use leal

<damo22>so the instruction fails

<youpi>to compute the address without dereferencing it

<damo22>ah ok

<damo22>7ffd92847ec8

<damo22>7ffd13847ec8

<damo22>asm ("leaq -0x7f000000(%[rax],%[rbx], 8), %[rcx]"

<damo22>it does not look like it extends the offset to 64 bits

<damo22>if it did, the top bits above would be cleared?

<youpi>I vaguely remember that x86_64 mostly uses relative 32b adressing to reach variables, and it has an rip-relative mode that makes it convenient

<youpi>leaq variable(%rip), %rax

<youpi>(or movq, etc.)

<youpi>so it's a 32b offset

<damo22>yeah

<damo22>so i have written macros such as:

<damo22>+/* Workaround for missing 64 bit immediate for

<damo22>+ * offset(, reg, width) syntax */

<damo22>+#define OP_CX(op, a64, cpureg, tmpreg, reg) \

<damo22>+ movq $a64, tmpreg ;\

<damo22>+ op (tmpreg, cpureg, 8), reg

<damo22>so we can call that instead of:

<damo22>op CX(a64, cpureg), reg

<youpi>better use leaq a64(%rip),tmpreg

<youpi>that'll produce smaller code

<damo22>but a64(%rip) is relative to the current instruction but we have absolute addreses

<damo22>like labels

<youpi>that's not a problem, the linker will compute the offset

<damo22>a64 is the offset

<youpi>no it's a label

<damo22>ah ok really? thats a nice instruction then

<youpi>a reference will be left in the object, and the linker will compute the difference

<youpi>you can learn a *lot* from gcc-O2-compiled assembly

<damo22>im terrified to read GCC compiled assembly

<damo22>its so messy

<damo22>with function prologues and epilogues

<youpi>you can just discard that and read only the instruction

<youpi>these are just boilerplates

<damo22>ok thanks, goodnight

<youpi>gn

<Pellescours>you’re right ncpus=6 doesn’t work. I didn’t tried withhout ncpus yet (but I don’t see any reason why it would not work). But when I try to run gnumach smp (i386), it always hang at rumpdisk step (even with the commit reverted)

<azert>Pellescours: that’s a recent regression https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00019.html

<azert>someone should contact the author of that commit to let him know

<Pellescours>azert: I know, I’m telling that even with this commit being reverted my gnumach hang

<youpi>damo22: btw, we build the kernel with -mno-red-zone to simplify interruption code, so -4(%rsp) is not supposed to be valid :)

<gfleury>Pellescours: how do launch qemu. Note that -smp 2 is still broken even if you you revert that commit

<gfleury>I have compiled gnumach with --enable-apic --enable-ncpus=4

<gfleury>Run qemu with -smp 1 or 3 or 4 work

<damo22>Pellescours: which branch hangs?

<damo22>s/branch/commit

IRC channel logs

2026-01-03.log