IRC channel logs
2023-02-13.log
back to list of logs
<luckyluke>so maybe a starting point could be to first have mig generate the code for the new message layout, and in the meantime try to run a 64 bit userspace? <youpi>flavioc: ok, so re-shuffling the content of messages. I'm a bit afraid of the introduced changes to convert for the 32-on-64 case, but we'll be able to just get rid of it once when we get rid of 32bit support <youpi>if that's what other mach kernels do, that's probably better to migrate to it as well <flavioc>youpi: mig should still generate the old format for 64-bits on 32-bits <flavioc>unless we really want to make sure the kernel has no undefined behavior, for the 64-bit on 32-bit kernel case <youpi>I mean, on the long run we won't carry 32Bit support <youpi>so we don't care about previous mig format <flavioc>I was just thinking whether we really want to carry 64/32 bit for a long time, otherwise we should make sure there's no UD :) <youpi>we don't have alignment UB issues <flavioc>probably not since we likely don't have pointers or 64 bit scalars in structures that we use in the kernel when doing RPCs <youpi>actually we have the 64bit value in vm_allocate_contiguous for physical addresses <youpi>(that's the only one I can see, other counters are (unfortunately) all 32b) <flavioc>I think it might be fine in this case because it is a simple scalar <flavioc>would have to look at the generated code to see what instructions does GCC generate <youpi>thus making structures containing it 8 too <flavioc>GCC in this case knows that it is misaligned <flavioc>but depends on what kind of pointer it sends to the routine <youpi>but yes, if we know that case to be fine, I'll say "ok, fine with it" :) <youpi>I'm wondering about the word_size -> max_alignof changes in your patch, it shows that padding gets added here and there, is that what you'd want to avoid with untyped messages ? <youpi>(that's indeed quite significant) <youpi>ok, we'd be able to pack the complex data naturally, and large-align once for the non-complex data <youpi>that kinds of reverts the max_alignof patch you have sent just hours ago, sorry for that <flavioc>I think it would be useful to merge that one, at least since it removes word_size and we still need a concept of max_alignof <youpi>I'm not actually sure we have a max_alignof at all <youpi>I mean, we don't want to align 32bit complex values on 64b <youpi>and also, do we actually want to align <32b complex values on 32b? <youpi>the only general alignof I can think of is saying "we don't know what's in the non-complex data, we just align to an arch-specific amount, typically sizeof(uintpt_tr)" <flavioc>that's why we also have per type alignment <youpi>yes, that's all we should care of <youpi>if the type we're about to *start* with doesn't have its alignment requirement met, pad <youpi>thus possibly padding for various field, but only if its alignment is not met <flavioc>that's true for the new message format not for the current format <youpi>I don't see why forcing consecutive byte fields on 32b alignment <youpi>yes, we have to stay compatible with the old <flavioc>otherwise we would have to encode the alignment for each data item in the message itself <flavioc>right now, we assume it is 4-byte aligned, so the kernel knows how to jump between items easily <youpi>so we can keep a min_alignof that is 4B for compatibility, and 1B with the new format <youpi>ah, there's an additional alignment requirement: the type fields themselves indeed <youpi>all in all, I'm thinking that we want your patch, but with the complex_alignof name instead of max_alignof, and call max_alignof the alignment of the non-complex data <youpi>that explicits that we'll keep 4-byte alignment for complex data (while still allowing 8-byte complex data, duly aligned accordingly), and align non-complex data further (I'd say make it 16-byte aligned on 64b, to be safe, since the x86_64 ABI asks such alignment for stacks etc.) <youpi>if you're ok, I can commit your patch+sed(s/max_alignof/complex_alignof) <flavioc>I have a patch that makes mach_msg_header_t the same size in both kernel and userland on 64 bits (32 bytes). any concerns with that? we won't need resizing and mig won't need to know that kernel and userland have different sizes <youpi>you mean by extending the two port fields to 64b ? <youpi>that actually looks better to me <flavioc>one of them is already extended due to payloads <youpi>yes and it's then oddly aligned <youpi>gnu_srs1: about golang build issues, note that the ‘unix.TIOCGETA’ issue is already solved, it's just that debian got a newer package that dropped the cherry-picked patch <youpi>(that I had uploaded to unreleased) <Pellescours>damo22: with you last branch, with 1 cpu, there is still the problem of cpu running a 100% while we do nothing <Pellescours>I saw in htop that the first task is marked in D state <Pellescours>so I don't know if that can help you to find the cause of the 1st task dying with 2 cpus <gnucode>just curious...what do you all think about this latest nullprogram post?