IRC channel logs

<solid_black>yeah, but I hoped that'd be the case only for the main CPU core, since it has to keep compatibility, but not for other cores which could just have an explicit flag for starting in 32-bit/64-bit mode

<solid_black>which the main CPU would pass, I mean

<damo22>nothing is passed

<damo22>it starts in CS:0

<damo22>pretty sure the IPI that is sent to wake up the AP is given an 8 bit number as the (start address >> 12)

<damo22>that tells it which CS to set

<damo22>it expects code to be there

<youpi>damo22: a mere jmp won't clear the instruction cache

<damo22>hmm ok

<damo22>i saw that in netbsd code, i thought it would

<youpi>dumb pipelined processors would indeed flush the pipeline, but if processors nowadays were like that we'd lose a lot of time in ifs/loops/etc.

<damo22>isnt real mode x86 a dumb pipelined processor?

<solid_black>how does that work compatibility-wise?

<solid_black>an older OS written for pre-speculation processors wouldn't be aware that theu need to flush?

<anatoly>solid_black: https://mjg59.dreamwidth.org/66109.html some fun reading about modern Intel x86 boot process

<solid_black>hi anatoly

<anatoly>heya!

<damo22> * Flush instruction pipelines by doing an intersegment (far) return.

<youpi>intersegment would indeed flush

<anatoly>solid_black: have you seen my message re. new images, etc after your message re. new changes? :-D

<solid_black>I have, cool

<solid_black>I haven't tried pulling & using the images themselves though

<youpi>it's very common that people assume that the behavior they see is the expected behavior, and rely on that, but that has also commonly posed problem when the reality has changed

<youpi>e.g. people using memcpy for areas that do overlap

<anatoly>solid_black: all good, no worries :-)

<damo22> /* Flush the prefetch queue */

<damo22> jmp 1f

<damo22>1:

<damo22>that is enough on amd64

<youpi>this looks plain broken to me

<youpi>if that was really flushing the prefetch queue, our processors would lose a *lot* of time for each if we perform

<damo22>maybe it applies only in real/protected mode but not in long mode

<youpi>the pipeline flush performance hit would be the same

<damo22>maybe x86 just does suck that badly

<damo22>ive asked netbsd, see what they reply soon

<youpi>self-modifying code is really a thing fro mthe past

<damo22>so is 16 bit mode

<youpi>I don't see how intel could have made so long pipelines in pentium 4 without properly predicting jumps

<youpi>yes, but conversely, I find people saying that e.g. 486 is hit by the self-modification issue

<youpi> https://groups.google.com/g/comp.arch/c/k8tKb2TzufM

<youpi>« IA-32 processors exhibit model-specific behavior when executing self modified code »

<anatoly> https://riptutorial.com/x86/example/20472/wake-up-all-the-processors - ow I learned a bit about waking up APs and SIPI

<anatoly>*now :)

<damo22>from everything you posted, i still think my code is correct :)

<damo22>alternatively, could we reserve a page or two of memory at an absolute address below 1MB and tell gnumach vm to avoid it?

<anatoly>solid_black: do you have instructions of how to build qemu image from the result of cross-building?

<anatoly>solid_black: what is the issue with building grub package?

<damo22>(08:35:16 PM) mlelstv: damo22, it still works and is necessary in 32bit protected mode. not sure about 64bit. <--- i trust what this guy says more than what i can come up with from reading specs sometimes

<youpi>damo22: I rather think that the code might work just by luck. We don't want code that just works by luck

<etno>damo22: low memory areas typically used by DOS should be available. Telling gnumach to not use them would consist in asking gnumach to reserve that physical location. I believe that this is what is done in the deep of vremap()

<youpi>as of reserving a fixed-address page, e820 might tell you that no it's actually reserved for the bios

<youpi>"works" is not good enough for building an OS...

<damo22>cant we use e820 to locate a page that is below 1MB?

<youpi>yes but then it'll be dynamic

<youpi>exactly what we are at

<damo22>oh right

<damo22>there is a 3rd option

<damo22>0xff opcode, apparently works on "/5" models

<damo22>its the same as 0xea but allows memory location to be passed in

<youpi>it's not "allows", but "expects" :)

<damo22>yes

<damo22>i dont know how to assemble it though

<youpi>you'd put .byte 0xff so as to modify the adresse anyway, won't you?

<damo22>yes, but how do you pass a register value to something that is not an instruction?

<youpi>?

<damo22>eg:

<damo22>.long (%eax)

<youpi>that won't work of course

<youpi>the assembler doesn't know what value to put there

<damo22>right

<damo22>so how do i code the 0xff instruction

<youpi>I don't know what exactly you want to assemble

<damo22> https://i2.paste.pics/QAKDD.png

<youpi>if you want to use a register, you're doomed, it seems that far jumps don't want registers

<damo22>the bottom one

<youpi>that's memory-only, not registers

<youpi>so it's the processor itself that doesn't support registers

<damo22>yes, but we can load the value into memory

<damo22>and then point at it?

<youpi>you'll probably need the absolute address of that variable

<youpi>thus back to square 0

<damo22>heh

<damo22>i can use variable-apboot

<damo22>but i need to add X

<youpi>that won't work once you have loaded the first bootup segment

<youpi>really, can't you just write the relocation from the C code?

<damo22>i dont know what that would involve

<youpi>just put a label and a .globl

<youpi>and then you'll be able to write to it from C code after a extern declaration

<damo22>ok

<damo22>i patched the gdt that way

<damo22>but can i refer to the variable in the ljmpl?

<damo22>as an immediate?

<damo22>or only its offset

<damo22>arent we back to square 0?

<damo22>(08:47:26 PM) mlelstv: n.b. the comment is misleading.

<solid_black>anatoly: I did add some instructions to README.hurd.md last time, have you seen them?

<solid_black>grub just depends on various things

<youpi>damo22: actually you don't need the 0xff variant if you're relocating from the C code

<youpi>you can just use the current v2 patch, but write to ljmp_offset32 from C code

<anatoly>solid_black: sorry, haven't check the diff, will do

<solid_black>I have made quite some progress on building those too, I have e.g. libpng and python3 and libxcb and libx11

<anatoly>solid_black: ah, so ir

<solid_black>basically all the dependencies required to build freetype, but freetype itself doesn't yet build

<solid_black>ir?

<damo22>(09:02:31 PM) mlelstv: in 8086 a jump obviously has to drop a prefetched instruction. But if your CPU got a deeper pipeline, it may also need to flush at least part of the pipeline state. But that depends on what state actually changed. A switch to a different mode

<damo22>(09:02:32 PM) mlelstv: affects how instructions are interpreted, so there you need to flush most things.

<damo22>(09:02:51 PM) mlelstv: but not necessarily the "prefetch buffer" which is a cache nowadays.

<damo22>(09:05:08 PM) mlelstv: my guess is that a jump (that stays in the same mode) currently flushes the speculative buffers, but only if the branch was mispredicted.

<anatoly>solid_black: so it's so far matter of going the tree up and build deps

<youpi>damo22: yes, and a jmp 1f; 1: is always predicted

<solid_black>it may be easier to wait until we can build packages natively rather than cross-compiling, because most alpine packages outside of the core bootstrap path were never written with cross-compiling in mind

<solid_black>but that's just a "might", it might also be easier to make it cross-compile, who knows

<damo22> 0: 66 ff 28 ljmpl *(%bx,%si)

<solid_black>I think that while CI / packages repo is surely important, the most pressing issue to work on is making OpenRC boot fully work, and ensuring we have networking

<solid_black>networking, with dhcp

<anatoly>solid_black: I meant only grub's deps tree not whole distro

<solid_black>for that, we might need to build/package netdde, which is a good idea anyway

<anatoly>can't disagree :-)

<damo22> 0: 66 67 ff 28 ljmpl *(%eax)

<solid_black>also we want to build/package rump, and whatever was needed for acpi

<solid_black>help welcome, but I should be able to figure that out myself eventually, too

<solid_black>have you seen my magnificent hack for ldconfig / glibc.trigger?

<anatoly>not yet, but most likely I won't get the idea how the hack is hacky :-)

<damo22>.code16

<damo22>addr32 ljmpl *(%eax)

<damo22>gas works on that

<solid_black>oh and also that ext2fs crash

<solid_black>we should figure that out

<anatoly>solid_black: so next for me is to create vm image and then I'll be able to experience all of that

<solid_black>yeah

<solid_black>would be cool to see if you would be able to reproduce the same issues / get the same things working

<solid_black>please let me know if the instructions are not clear enough

<anatoly>solid_black: sure

<solid_black>still waiting for a re-review on https://github.com/go-gitea/gitea/pull/28899

<anatoly>solid_black: I han an issue pushing the repo to gitlab, seems like history is too big so it times out on one of their checks during push.

<solid_black>you could try to sync things with the apstream alpine on GitLab side?

<solid_black>is there a mirror of upstream aports on gitlab.com?

<anatoly>solid_black: so i went the other way and imported project in gitlab by URL from alpines gitlab that went well and then I was able to add your remote and also move my commit.

<solid_black>or like that, yeah

<anatoly>solid_black: dunno. I will add their remote as upstream as some point but so far I follow your branch as upstream

<anatoly>*at some point

<damo22>0xff opcode does not jump interseg

<damo22>so it doesnt go into protected mode

<damo22>or i used it wrong

<anatoly>solid_black: right, mounting a disk image, hm, that's not that straightforward to execute within a container :-)

<solid_black>try --privileged

<solid_black>or, the way I did it, mount it outside of the container, and pass it intside as a volume

<anatoly>solid_black: yeah, I know :-) the second options is the option

<solid_black>quick quiz: how would you bind-mount an fs on the Hurd?

<solid_black>the answer is /hurd/firmlink

<solid_black>we don't have busybox udhcp, because of course it's Linux-specific :(

<anatoly>solid_black: why do you need to "apk fix" things?

<solid_black>because you're installing with --no-script

<solid_black>'apk fix' reinstalls the packgage, running the scripts this time

<anatoly>ah, right, I see

<solid_black>so you get all the symlinks to busybox, glibc gets to generate /etc/ld.so.cache, and the Hurd gets to install the translator nodes and blow up the filesystem

<anatoly>yep, it makes sense

<solid_black>also be aware that PATH is just /bin:/sbin by default for some reason, i.e. no /usr there, but some binaries are in /usr

<solid_black>so you may want to add to your PATH

<solid_black>you can 'aok add bash' for a better shell experience, it totally works :)

<solid_black>run 'setup-hostname' to rename the host, and reexec bash ('exec bash') to have it update in your prompt

<anatoly>solid_black: thanks!

<solid_black>anatoly: so, any luck?

<saravia> /clear

<gnu_srs>Hello, the following statement causes problems with dhcpcd:

<gnu_srs>ctx->link_fd = xsocket(PF_ROUTE, SOCK_RAW | SOCK_CLOEXEC | SOCK_NONBLOCK, AF_UNSPEC)

<gnu_srs>Problem is that PF_ROUTE is defined in socket.h but not implemented, causing an error.

<gnu_srs> Any hints of a workaround/replacement?

<youpi>gnu_srs: the SIOCADDRT ioctl, probably

<gnu_srs>Maybe the entry of PF_ROUTE in socket.h should be commented out as PF_LINK is?

<youpi>we could indeed

<damo22>youpi: ljmpl *(%eax) does not cause the processor to switch modes

<damo22>do you want me to use C code to write to ljmp_offset32 ?

IRC channel logs

2024-01-30.log