channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev2&y=24&m=7&d=7
00:02:00 <heat> book
00:58:00 <adder> I wanted to enable interrupts and try and get keyboard input (not necessarily just because of this), so I read the 8259 tutorial but then realized it's a thing of the past and that now APIC is where it's at
00:59:00 <adder> so my question is, can I ride on 8259 for a while? It's a little too overwhelming to tackle APIC now when I haven't reached the long mode yet even
01:00:00 <nikolar> you can
01:00:00 <nikolar> especially if you don't care about other cores yet
01:00:00 <adder> ok, that's great
01:00:00 <adder> thanks, nikolar
01:00:00 <nikolar> no problem
01:49:00 <zid`> liberapls
01:54:00 <nikolapdp> libera is liberaing
02:10:00 <adder_> does it matter if I first load idt then remap pic?
02:11:00 <adder> getting a panic somehow
02:19:00 <heat> not if you keep interrupts off
02:19:00 <adder> they are off, in the sense that I didn't sti
02:20:00 <adder> it's just a panic out of nowhere, not even in the path that could trigger it
02:28:00 <zid`> ..panic?
02:29:00 <zid`> cpu's don't have panics, do you mean #GP?
02:32:00 <adder> I meant the function in my code that's supposed to panic, runs
02:32:00 <adder> like nothing in the path calls it
02:33:00 <zid`> is it next in the binary and you fell through to it? :P
02:33:00 <zid`> corrupted your stack?
02:33:00 <adder> could be
02:33:00 <zid`> qemu can instruction trace
02:33:00 <zid`> if you absolutely need it
02:34:00 <adder> you know what was it
02:34:00 <adder> previously I had printf("%d", 1/0); as the last line, now I removed that it I suppose as you said it fell through from a noreturn func
02:35:00 <zid`> ta-da
02:35:00 <adder> now halting the machine stops it
02:35:00 <adder> thanks zid
02:36:00 <zid`> https://godbolt.org/z/j1safM9bP Got me interested in what gcc would actually generate for that
02:36:00 <bslsk05> godbolt.org: Compiler Explorer
02:39:00 <adder> yeah it was an invalid opcode, but initially I had wanted a division error or whatever
02:40:00 <zid`> you'll need to obfuscate it or do it in asm if you genuinely want that
03:11:00 <adder> what does this look like to you? https://imgur.com/screenshot-RuzxInR
03:11:00 <bslsk05> imgur.com: Screenshot - Imgur
03:12:00 <adder> https://bpa.st/AJCQ
03:12:00 <bslsk05> bpa.st: View paste AJCQ
03:22:00 <gcoakes> I'm writing a toy kernel mostly for educational purposes. I have some of the basics done (boot, serial console, shutdown). I want to enable virtual memory and start a userspace program (like seL4's root task). I'm thinking I'll identity map all the existing memory when running within the kernel. That way I can avoid something like Linux's vmlinux image or seL4's multi-stage embed elf image for the kernel. Can someone dissuade me from
03:23:00 <gcoakes> I feel like there must be something wrong with that design if seL4 and Linux use multi-staged boot processes with embedded kernel images for the virtual memory enabled stage.
03:57:00 <zid`> identity mapping your kernel is weird
04:16:00 <adder> so I'm getting an exception for some reason
04:16:00 <adder> can't make sense of all this output in qemu
04:18:00 <adder> a gpe
06:03:00 <geist> a gpf? what was the error code
06:04:00 <geist> generally speaking the program counter at the place it GPFed and the error code is enough to figure it out
06:04:00 <geist> or at least figure out what class of problems it is
06:11:00 <kazinsal> based on the paste, my magic 8-ball (which you get after doing this hobby for entirely too dang long) says the combination of a single hlt after sti and [[noreturn]] means you're infinitely executing garbage
06:30:00 <adder> I seem to have narrowed it down to loading the gdt somehow wrongly... qemu says GDT= 00000000 00000000
06:31:00 <zid`> what about GDTR
06:32:00 <adder> I'm calling gdt_flush, and then from assembly, lgdt gdt_ptr, where gdt_ptr is struct u16 u32 packed
06:32:00 <adder> then a ljmp
06:33:00 <adder> this code worked just fine but for some reason it doesn't now
06:33:00 <zid`> what about GDTR
06:33:00 <adder> ah you mean in qemu?
06:33:00 <zid`> yes in qemu
06:34:00 <zid`> it was in response to "qemu says GDT="
06:34:00 <adder> I don't see gdtr the way I run qemu (-d int)
06:35:00 <zid`> ah yea it's just called GDT but means the GDTR
06:35:00 <zid`> oops
06:35:00 <zid`> yea it shouldn't be 0 0 unless something messed up
06:36:00 <zid`> might be worth putting a breakpoint on the lgdt [blah] line and checking it takes correctly
06:37:00 <adder> thanks, I guess I'll try that
06:37:00 <adder> let me first try to bisect the thing and try and see where it went wrong
07:18:00 <adder> so, nothing was wrong... what kazinsal said is even the most likely :)
07:18:00 <adder> so I want to capture keyboard input, but I'm not sure if that makes sense before I transfer control to the kernel?
07:19:00 <adder> otherwise I'll have a "sti" and a "hlt" (so that I don't fall through) and it's difficult (impossible?) to get anything
07:20:00 <zid`> why not just put an infinite jump in, then you don't have to play silly games with interrupts working in certain ways
07:20:00 <adder> so I'd need to move on now and then get back to interrupts later once the kernel has the control
07:20:00 <zid`> and put in a "you shouldn't be able to get here" printf or something too for good luck
07:20:00 <zid`> this is development code, do things to make your life easier
07:20:00 <zid`> once it works you can tidy it
07:20:00 <adder> yeah no probs
07:20:00 <adder> jump from I assume asm?
07:20:00 <adder> to where?
07:22:00 <adder> or did you mean I should put in place a fake kernel and then jump there?
07:22:00 <adder> this strikes me as a good idea
07:25:00 <geist> so you can confirm it's the GDT by adding a infinite loop just after doing the GDTR, then droppimg into qemu and see what it thinks GDTR is
07:26:00 <geist> `info registers` should show it
07:26:00 <adder> sorry, did zid mean infinite loop or jump infinitely forward?
07:27:00 <adder> gdt looks just fine once I don't fall through from noreturn
07:27:00 <zid`> int noreturn this_function_you_keep_talking_about(){ .... while(1); }
07:27:00 <zid`> There, now it can't fall through, considering you've added this bug.. 4 times?
07:28:00 <zid`> you can test removing it later on, once it all works as expected
07:28:00 <zid`> it's just making your debugging experience very difficult not doing it
07:28:00 <adder> ah okay :)
07:30:00 <adder> 0xd again
07:30:00 <adder> this time gdt looks alright
07:30:00 <kazinsal> along with your osdev magic 8-ball comes a sixth sense. it's meant to offset the fact that decades of fighting with bare metal and the subsequent acquired taste for hard liquor dulls your first five
12:16:00 <kof673> > "you shouldn't be able to get here" quote: I know Quake has "You're not supposed to be here" but i didn't know Duke has too ...the flood level if you get a jetback and fly up to a cave, there is graffiti on the wall IIRC "you shouldn't be here -- miniboss" something like that :D
12:16:00 <kof673> just put a little ascii art miniboss head at these parts of the code :D
12:17:00 <mjg> quake?
12:17:00 <mjg> where
12:17:00 <kof673> i don't know, was trying to find the duke 3d thing...that came up..can't be bothered...
12:18:00 <mjg> i never heard of it
12:18:00 <mjg> and i was pretty into quek
12:19:00 <mjg> so it is a thing https://www.youtube.com/watch?v=8YdFeNmzkO4 at least in the remaster
12:20:00 <bslsk05> 'Quake | You're not supposed to be here achievement | Tur Torment Secret achievement' by Dream's Guides (00:01:57)
12:20:00 <mjg> this is defo not part of the base game
12:20:00 <mjg> i mean the map itself is from one of the mission packs
12:23:00 <kof673> it may very well be some 80's movie quote
12:34:00 <kof673> wherever it is, i think "miniboss" was just a nick of a level designer, but i prefer the other interpretation, that he wrote in blood to mock you :D
14:58:00 <adder> I'm getting a GPF after initing gdt, idt, remapping pic, and sti, and would appreciate some pointers as to how to debug this
14:58:00 <adder> I should note that my gdt only contains 5 items, null descriptor, plus two code/data segments for kernel and user (no tss)
15:17:00 <gog> adder: are you using gdb
15:18:00 <gog> and do you have a GPF handler in your IDT?
15:18:00 <gog> alternatively, you can add -d int to qemu and you can find the contributory faults if there are any
15:18:00 <gog> because if an interrupt is happening with no corresponding entry in the IDT, it'll #GP
15:28:00 <adder> gog, no, I'm not using gdb. -d int says it's 0xd, and it is what I see (I have a handler that panicks on it)
15:29:00 <adder> I believe I have reserved 32-256 correctly in the idt
15:29:00 <heat> what's the error code, what's the IP
15:29:00 <heat> what instruction is GPF'ing?
15:30:00 <adder> uh how can I check?
15:31:00 <heat> get the IP, disassemble that address
15:34:00 <adder> 0x000000000010275b: iret
15:35:00 <heat> what's the error code?
15:39:00 <adder> int_err_code seems to be 512
15:39:00 <adder> (I printed this out, lmk if there's a better way to check)
15:40:00 <heat> sounds like your stack is borked and you're iret'ing with bad state
15:40:00 <heat> namely either ss or cs are 512
15:40:00 <adder> ok, thanks for the hint
15:40:00 <adder> let's see
16:13:00 <adder> so.. seems like I'm seeing irq8
16:14:00 <adder> I try to eoi it but that's the first and the last of what I see
16:20:00 <adder> need to get some sleep, thanks all
17:55:00 <elttil> Hello, I appear to be having a problem with recieving incoming packets on QEMU with the rtl8139 NIC on my OS. It seems as if I can only get roughly 6000 incoming packets(it varies) until it can not recieve anymore. Even QEMU seems to agree that there is no incoming packet as when I check the netlog it states no incoming packets occur eventough I know they have been sent. I have tried both sending via port the QEMU hostfwd and by initating a DNS request which doe
17:55:00 <elttil> s go out according to netlog but gets no incoming packet.
17:55:00 <elttil> Here is how I launch QEMU
17:55:00 <elttil> qemu-system-i386 -enable-kvm \
17:55:00 <elttil> -netdev user,id=n0,hostfwd=tcp:127.0.0.1:6001-:80 \
17:55:00 <elttil> -device rtl8139,netdev=n0\
17:55:00 <elttil> -object filter-dump,id=id,netdev=n0,file=./logs/netout\
17:55:00 <elttil> -no-reboot -no-shutdown\
17:55:00 <elttil> -chardev stdio,id=char0,logfile=./logs/serial.log,signal=off\
17:55:00 <elttil> -serial chardev:char0 -drive id=disk,file=./meta/ext2.img,if=none\
17:55:00 <elttil> -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0\
17:55:00 <elttil> -m 2G -cdrom ./kernel/myos.iso -s
17:57:00 <elttil> Here is my netout file, I have made sure to increase the maxlen but that does not appear to be the issue: https://0x0.st/XBw4.pcap
18:00:00 <heat> it could be a qemu bug
18:00:00 <heat> have you asked them?
18:01:00 <elttil> No I always assume I am doing something wrong before that(it is usually the case). I just wanted to know whether this was a known issue
18:02:00 <heat> i personally have not seen a similar bug
18:03:00 <heat> does it repro with linux?
18:04:00 <elttil> I have not tried it yet
18:14:00 <acidx> elttil: I've had issues with OpenBSD in qemu using this device too, FWIW
18:19:00 <elttil> I just tried it with debian using nginx and it does not appear to have the same issue
18:19:00 <elttil> acidx: Was it frequent and noticable or rare? For me it always happens in a very predictable way.
18:20:00 <elttil> Also did you report it anywhere?
18:20:00 <heat> it could be that a buggy or unusual driver/network stack is triggering some bug
18:20:00 <heat> what qemu version?
18:21:00 <geist> was gonna say maybe it has to do with wrapping the receive buffer on 8139, which is notoriously buggy
18:21:00 <geist> but 6000 packets it should have wrapped many times
18:21:00 <elttil> QEMU emulator version 7.2.9 (Debian 1:7.2+dfsg-7+deb12u5)
18:21:00 <geist> if you report it i'm sure they'll ask you to run the current version (9.0.1) and see if it reproduces
18:21:00 <heat> hmm, that's old
18:21:00 <heat> CLASSIC DEBIAN
18:22:00 <geist> also that's neat: the filter-dump netout stuff i have never known
18:22:00 <geist> that's helpful
18:23:00 <heat> yeah i have one set up permanently
18:23:00 <heat> qemu can generate its own pcaps
18:25:00 <zid`> looks kind of fun to debug though
18:25:00 <zid`> you can just trace the entire path to see where they go missing
18:26:00 <nikolapdp> well there you go zid`, a fun weekend project for you
18:26:00 <zid`> not my system
18:29:00 <geist> still, might be worth checking the wraaround issue on rtl8139
18:29:00 <geist> iirc there's a quirk and/or bug that concerns what happens if a packet starts basically right at the end of the buffer
18:29:00 <geist> soething to do with the header getting cut off, or it extending 16 bytes past the end of the buffer, or something
18:29:00 <geist> presumably qemu emulates the hardare
18:30:00 <zid`> I'd just add a printf or to the qemu side because I don't know the logging options, am I a bad person
18:32:00 <geist> or if you let it overflow it triggers an overflow interrupt and i think yo uhave to reset the rx path and start over
18:32:00 <nikolapdp> you aren't, as long as you delete it later
18:32:00 <zid`> do I have to?
18:33:00 <elttil> It is very possible it is a issue with the wraparound as I have somehow messed it up multiple times. Maybe this time I messed it up so badly that it breaks qemu
18:33:00 <geist> well maybe not so uc breaks qemu but causes you to get out of sync such that you'll receive no more packets
18:33:00 <elttil> well that does not appear to be the case since qemu does not write stuff to the netlog
18:34:00 <nikolapdp> yes
18:34:00 <geist> true though maybe it only writes it to the log if its succesfully delivered to the nic
18:34:00 <geist> and if the nic is overflowed or something it might drop the packet pre-netlog
18:35:00 <heat> send a bug report to qemu-devel
18:35:00 <heat> see what they say
18:35:00 <heat> even if 9.0.1 works properly, cuz they'll probably want to backport the fix anyway
18:37:00 <zid`> the rtl8139 code does a lot of DPRINTF in the recv path at least
18:39:00 <zid`> but once it gets past the receiver enabled etc checks it's pretty brainlessly just writing stuff then triggering the irq
18:40:00 <zid`> so imo if a packet shows up at all, it doesn't look like it can wedge
18:40:00 <kof673> i notice moss (ancient djgpp-like thing) needs "\r\n", at least when ran under windows 3.1 ms-dos prompt... how portable are these printf()s? j/k
18:41:00 <zid`> I wonder if it's just that the socket got disconnected somewhere inside qemu or something, personally
19:01:00 <elttil> Well after having compiled QEMU version 9.0.1 and testing with that it appears to be working just fine.
19:02:00 <elttil> First time it was not my fault :D
19:06:00 <heat> maybe bisect and report upstream if you can
19:06:00 <heat> the stable distro people probably want to apply that patch
19:06:00 <heat> also ROLLING RELEASE WINS AGAIN
19:07:00 <heat> i like life experiences that reinforce my views
19:07:00 <Ermine> need to set up distcc
19:07:00 <nikolapdp> rolling release wins every time heat
19:07:00 <nikolapdp> Ermine what for
19:07:00 <nikolapdp> i need to do that to
19:07:00 <nikolapdp> too
19:08:00 <heat> obviously ermine just saw this and is moving to GENTOO
19:08:00 <Ermine> no
19:08:00 <heat> darn
19:08:00 <Ermine> no way in hell
19:08:00 <heat> but you can use openrc :(
19:08:00 <Ermine> it's a perk for nikolapdp, not for me
19:09:00 <Ermine> I'm s6 fanboy
19:09:00 <Ermine> (or perp maybe)
19:09:00 <nikolapdp> Ermine i don't use openrc
19:09:00 <heat> skarnet software fanboy vs sysv init fanboy vs systemd fanboy
19:09:00 <heat> what the heck do you use then
19:09:00 <nikolapdp> runit
19:10:00 <Ermine> I'm writing from systemd-powered distro
19:10:00 <heat> ohhhhhh that's a thing
19:10:00 <nikolapdp> i am not
19:10:00 <Ermine> and going to install another one
19:10:00 <nikolapdp> i am writing from a 2.11 BSD distro
19:11:00 <heat> Ermine, the best part about systemd is that you literally will never need to think about the init system ever again
19:11:00 <heat> except when periodically restarting pipewire
19:11:00 <Ermine> anyway, I want to work on my pc, but my laptop happened to be more powerful
19:11:00 <Ermine> heat: I've thought about my init system on this weekend, literally
19:12:00 <Ermine> due to weird interaction of plasma and systemd
19:12:00 <heat> plasma interacts weirdly with humans too
19:12:00 <nikolapdp> heat i literally never think about my init system either
19:12:00 <nikolapdp> what's your point
19:13:00 <Ermine> yes, that interaction have lead to a weird interaction of me with my computer
19:13:00 <Ermine> Instead of playing Zuma
19:13:00 <heat> you thought about it long enough to purposefully switch to a smaller distro with hipster alternatives
19:13:00 <heat> or you just thought artix is a cool name
19:13:00 <heat> and fair enough, it is a cool name
19:13:00 <nikolapdp> you'll never know
19:13:00 <nikolapdp> what i meant is that i don't think about my init system while using my system
19:14:00 <heat> Ermine, do alpine packages need to work around not having systemd often?
19:14:00 <Ermine> I only thought about whether I can be bothered to switch to non-systemd distro
19:15:00 <nikolapdp> i can say for artix that, sometimes, package have broken scripts that don't let you disable systemd even when they don't require it
19:15:00 <nikolapdp> *packages
19:15:00 <Ermine> heat: does removing /usr/lib/systemd from pkgdir and -Dsystemd=false count? If no, then not
19:15:00 <heat> i would imagine most daemons written for the last 10 years do not have openrc/runit/sysv/s6/whatever scripts but just systemd unit files
19:16:00 <nikolapdp> Ermine are you a maintainer of alpine
19:16:00 <Ermine> that's true
19:16:00 <Ermine> nikolapdp: yes
19:16:00 <nikolapdp> i wanted to see what you (alpine) did for new nbd
19:16:00 <Ermine> nbd?
19:16:00 <nikolapdp> they changed (broke) their configure to require systemd
19:16:00 <zid`> nikolar why are you a museum
19:16:00 <nikolapdp> zid` museum?
19:16:00 <zid`> yes
19:16:00 <nikolapdp> how
19:17:00 <zid> what do you mean HOW
19:17:00 <zid> You're running bsd 2.11 on a pdp11
19:17:00 <zid> the fuck do you think I mean
19:17:00 <nikolapdp> i am not a museum, i am a human
19:17:00 <zid> speak serbian technology
19:17:00 <zid> peak*
19:17:00 <nikolapdp> lol if only i could find a pdp-11 here
19:17:00 <zid> get one of your russian clones
19:18:00 <nikolapdp> they suck
19:18:00 <nikolapdp> can't run unix
19:18:00 <zid> but can they run stalinix
19:18:00 <nikolapdp> also what do you mean my russian clones
19:18:00 <Ermine> heat: otoh there are rough edges that nobody worked around, mostly due to lack of systemd --user alternative in openrc
19:18:00 <Ermine> E.g. with dbus-daemon --session and pipewire launching
19:18:00 <nikolapdp> Ermine, i was referring to https://pkgs.alpinelinux.org/package/edge/community/x86_64/nbd
19:18:00 <bslsk05> pkgs.alpinelinux.org: Alpine Linux packages
19:19:00 <nikolapdp> but alpine doesn't have the problematic version yet
19:20:00 <Ermine> can you elaborate?
19:21:00 <Ermine> I don't use it often, but if you have some issue with it I can try to help
19:21:00 <nikolapdp> if you are curious, this is i how i got it to build, https://gitea.artixlinux.org/packages/nbd/src/commit/255f7eac21113b413cf1d6a2508cabdf6b347769/PKGBUILD#L27
19:21:00 <bslsk05> gitea.artixlinux.org: nbd/PKGBUILD at 255f7eac21113b413cf1d6a2508cabdf6b347769 - nbd - Artix Linux Gitea
19:21:00 <nikolapdp> i just wondered if there was a cleaner way
19:22:00 <heat> autoconf? run ermine run
19:22:00 <nikolar> lel
19:22:00 <heat> oh you're an artix maintainer too?
19:23:00 <heat> is everyone here a slave to the open source machine?
19:23:00 <nikolapdp> i think i've mentioned that a couple of times here, but yeah
19:23:00 <nikolapdp> heat your whole os is open source
19:23:00 <nikolapdp> are you a slave too
19:23:00 <Ermine> heat: yes, you can say so
19:23:00 <heat> yes i'm most definitely a slave to the FOSS machine
19:23:00 <nikolapdp> then we all are
19:24:00 <Ermine> (But i'd like to be more involved with Alpine, but my PESSIMALity prevents that)
19:24:00 <heat> yes
19:24:00 <heat> sample size of 3 is entirely representative of 260 people
19:24:00 <nikolapdp> is it not
19:24:00 <heat> it is
19:24:00 <heat> ermine is a maths guy he can back me up
19:24:00 <Ermine> if random enough
19:25:00 <nikolapdp> see, it's settled
19:25:00 <Ermine> I'm on academic leave though
19:25:00 <nikolapdp> doesn't matter, you're still qualified
19:25:00 <heat> that pkgbase.yaml stuff, is it package CI?
19:26:00 <Ermine> my qualified mates have already gratuated
19:26:00 <nikolapdp> heat it is, yea
19:27:00 <heat> btw what's the relation between arch and artix?
19:27:00 <heat> package-wise
19:27:00 <heat> you seem to maintain your own
19:27:00 <nikolapdp> we do, most our patches are to remove systemd
19:27:00 <nikolapdp> we sometimes patch things to fix arch's bullshit too
19:27:00 <heat> so you patch on top of arch?
19:27:00 <nikolapdp> minimally, but yeah
19:28:00 <Ermine> so, here's that plasma story
19:28:00 <nikolapdp> you'd be surprised how often arch's pkgbuilds don't actually build
19:29:00 <Ermine> So, I have Zuma installed through wine, and I've edited a .desktop file which launches it to use Gamescope
19:30:00 <heat> the trick is to just use steam and it usually just works
19:30:00 <nikolapdp> basically
19:30:00 <Ermine> It's pirated version
19:31:00 <heat> its 1EUR on steam rn
19:31:00 <nikolapdp> you can still run it through steam
19:31:00 <Ermine> Cool, but sanctions
19:31:00 <heat> cant buy from steam?
19:31:00 <nikolapdp> can i buy it for you and gift it to yo
19:31:00 <Ermine> yes
19:31:00 <heat> yikes
19:31:00 <Ermine> nikolapdp: no, thank you
19:31:00 <nikolapdp> lol ok
19:32:00 <heat> i want to buy euro truck simulator this sale
19:32:00 <nikolapdp> is the sale still on
19:32:00 <Ermine> so, anyway, I've launched plasma x11, and gamesope crashed, so game didn't work
19:33:00 <Ermine> I've removed gamescope invokation from that .desktop file
19:33:00 <heat> yeah sale's still on
19:33:00 <heat> no wayland?
19:34:00 <nikolapdp> no wayland
19:35:00 <Ermine> but plasma still tried to use gamescope. Even reboots didn't help
19:35:00 <Ermine> heat: let me finish first
19:37:00 <heat> yes boss
19:39:00 <Ermine> so culprit is that plasma created transient service units to launch stuff
19:39:00 <heat> wow that's cursed
19:39:00 <Ermine> and the fact I've edited .desktop files didn't affect those services
19:39:00 <Ermine> So plasma (or systemd) was using older command line which included gamescope
19:39:00 <nikolapdp> yuck
19:40:00 <Ermine> And I had to edit app entry using plasma's tool
19:41:00 <Ermine> so plasma updated the unit
19:42:00 <Ermine> re wayland: Zuma doesn't support any resolutions besides 640x800 or something like that, so modeset is needed to get to fullscreen and have the game stretched
19:43:00 <Ermine> (or gamescope, but I didn't figure out how to use it yet)
19:43:00 <nikolapdp> what about the steam version
19:43:00 <Ermine> Idk
19:44:00 <Ermine> if steam can get it through gamescope then maybe
19:47:00 <adder> I believe I'm seeing IRQ8 (clock) but the thing is it shows up only once
19:47:00 <adder> after that, no more interrupts of any kind
19:48:00 <adder> I'm handling it by https://bpa.st/QDXQ
19:48:00 <bslsk05> bpa.st: View paste QDXQ
19:48:00 <adder> I see "HERE!" printed out and that's the last thing I see
19:48:00 <heat> show me your interrupt handler
19:48:00 <heat> the assembly bits
19:48:00 <adder> one sec
19:49:00 <heat> also doing sti in an irq handler is unneeded and generally wrong
19:49:00 <adder> https://bpa.st/PJXA
19:49:00 <bslsk05> bpa.st: View paste PJXA
19:50:00 <heat> add $8, %esp
19:50:00 <zid> There's a command in qemu I forget
19:50:00 <zid> to show you the status of your interrupts
19:50:00 <heat> in line 69
19:51:00 <adder> that's an 8 then a buncha gpf
19:51:00 <zid> ofc you don't get more 8s then lol
19:51:00 <zid> you faulted to shit
19:51:00 <heat> have you tried the fix?
19:51:00 <adder> yeah I mean that's what add $8, %esp does
19:52:00 <heat> hmm
19:52:00 <heat> can you check if the stacks are "balanced" at entry and exit
19:52:00 <heat> i don't really recall how the i386 sysv calling convention works
19:53:00 <adder> do you mean that what gets pushed also gets popped?
19:53:00 <heat> yes
19:53:00 <adder> and am I supposed to do it manually?
19:53:00 <heat> yeah
19:53:00 <adder> gonna be a while I guess :)
19:53:00 <heat> as a quick hack you can do something like mov %esp, %eax then compare at exit
19:54:00 <heat> it'll corrupt your state, but it's already corrupted anyway
19:56:00 <adder> according to my inspection, push irq no, push 7 regs, push esp, then add $4, pop 7 regs, and it was add $4 again which you suggested to be add $8
19:57:00 <heat> it needs to be $8 cuz you need to clean up the error code too
19:57:00 <heat> isr number + error code = 8
19:57:00 <adder> yeah I see
19:58:00 <adder> I think I need to do more reading to see wtf exactly happens and what gest pushed, otherwise I'm getting nowhere
19:58:00 <adder> might this stuff be there in the intel/amd manuals?
19:59:00 <heat> of course
20:00:00 <heat> but generally your code looks right-ish, if you do add $8
20:01:00 <adder> hmm, then do we have irq8 followed by a gpf for some reason?
20:02:00 <adder> ah I know what to do, disassemble ip!
20:02:00 <heat> yeah do that
20:02:00 <heat> note: you also want to save/restore segment registers in the future
20:02:00 <heat> but it's not a problem atm
20:03:00 <adder> so qemu's going a little too fast, spinning somewhere in a loop
20:03:00 <adder> not sure how to input the command?
20:04:00 <adder> iret again
20:05:00 <adder> needs reading
20:10:00 <heat> uhhh can the pushal and popal be using the actual instructions instead of the macro?
20:11:00 <adder> it did not occur to me that there are actual instructions named that way, I'll try renaming
20:12:00 <heat> would probably not make a difference but, you know, it might be a problem
20:13:00 <adder> same outcome
20:13:00 <mjg> pushal, popal and paypal
20:13:00 <mjg> don't use the last one tho
20:13:00 <adder> let me read about this, I'll be stuck forever if I don't clear this up for myself
20:17:00 <heat> it could be that your gdt is busted
20:17:00 <heat> but i assume you tested that?
20:20:00 <geist> hmm, this is 32bit x86 right?
20:21:00 <geist> i guess so, because pusha doesn't exist on 64bit
20:43:00 <adder> idk man, I think they're alright
20:44:00 <adder> these are the entries https://bpa.st/SDFA
20:44:00 <bslsk05> bpa.st: View paste SDFA
20:44:00 <adder> and yeah I have the null descriptor
20:49:00 <geist> those look legit to me
20:50:00 <heat> can you give out the -d int dump?
20:51:00 <geist> also did you check that it was loaded right? ie, info registers after loading the gdt?
20:51:00 <geist> i didn't read the whole backtrace you may have already done it
20:52:00 <geist> but those are the first few things i'd always do
21:00:00 <chiselfuse> is there an easy setup i can have to locally have single-instruction to hex code translation like what https://defuse.ca/online-x86-assembler.htm does?
21:00:00 <bslsk05> defuse.ca: Online x86 and x64 Intel Instruction Assembler
21:01:00 <chiselfuse> and vice versa
21:01:00 <zid> you could write a shell script around nasm/ndisasm pretty easily
21:01:00 <zid> but yea, I use defuse.ca far too much :(
21:01:00 <geist> also if it's simple stuff you can try to use gcc.godbolt.org
21:01:00 <geist> oh i see, locally, yeah
21:01:00 <chiselfuse> zid: i'll try but i'm not sure i'll get the boilerplate right and all
21:02:00 <chiselfuse> wait isn't defuse.ca open source or something,
21:05:00 <chiselfuse> is this a valid instruction: mov r8d,QWORD PTR [rsp+0xb8]
21:05:00 <zid> Review: noodles aren't as good in the square packs of nong shim ramen compared to the big bowls
21:06:00 <heat> yes
21:06:00 <heat> wait, no
21:06:00 <heat> did something spit that out?
21:07:00 <chiselfuse> no, it was DWORD. i don't understand what's the significance of specifying that it's DWORD if no other size such as QWORD is valid
21:08:00 <geist> there's no requirement if its implicit
21:08:00 <geist> the width of the register implies it
21:09:00 <geist> where the size stuff matters (at least in att syntax) is something like pushing a integer to a memory location
21:10:00 <chiselfuse> does mov r8d, DWORD PTR ... also zero the top bits of the register?
21:10:00 <heat> yes
21:11:00 <heat> it's how every 32-bit partial register works in 64-bit
21:11:00 <heat> operations on the bottom half zero the upper half
21:11:00 <heat> like add eax, 0 zeroes the upper half too
21:11:00 <Mondenkind> so does mov eax, eax
21:11:00 <geist> and if you do want it to sign extend there's another mov variant
21:11:00 <Mondenkind> but xchg eax, eax does not
21:11:00 <heat> xchg does not?
21:12:00 <Mondenkind> yup
21:12:00 <geist> welcome to x86
21:12:00 <heat> yikes. is that a side effect of 0x90 being xchg eax, eax?
21:12:00 <Mondenkind> hint: nop is encoded as xchg eax, eax
21:12:00 <Mondenkind> yup
21:12:00 <heat> fucking lol
21:12:00 <geist> does xchg only exchange the lower 32 bits? or the entire 64bit reg?
21:12:00 <Mondenkind> they fixed this at like the last minute in the amd64 spec
21:13:00 <geist> ah yeah that makes sense, if it does nly the 32bit or the entire register it'd work as a nop
21:13:00 <geist> TIL some more useless minutae
21:14:00 <Mondenkind> looks like it's a special case for xchg eax,eax, so generally xchg r32,r32 would zero the high bits
21:14:00 <heat> what
21:14:00 <heat> you're making me really sad now
21:15:00 <chiselfuse> more info to add to my obsidian x86 notes
21:21:00 <chiselfuse> how about XCHG r32, r/m32 also only lower dword is exchanged?
21:25:00 <chiselfuse> zid: do you think i should use ndisasm or objdump for the script?
21:26:00 <zid> I prefer nasm syntax
21:26:00 <zid> so I'd do that, personally
21:26:00 <zid> also less bullshit to cut off the top
21:26:00 <zid> nidsasm just prints 000000: mov rax, 4
21:26:00 <Mondenkind> objdump -Mintel
21:27:00 <Mondenkind> chiselfuse: that exchanges the low dword of the register with the dword in memory, and zeroes the high bits of the register
21:27:00 <zid> # ndisasm -b64 kernel.bin | head -n1
21:27:00 <zid> 00000000 7F45 jg 0x47
21:28:00 <chiselfuse> i wish ida would show me the actual instruction without the autoanalysis, i have to switch to hex window to know what `mov [rbp+name], 8` actually is, then assemble that with defuse.ca
21:28:00 <heat> Mondenkind, have you heard about our lord and saviour at&t
21:28:00 <heat> they made UNIX!
21:28:00 <Mondenkind> wow it just keeps getting better and better
21:28:00 <zid> # objdump -b binary -D kernel.bin -mi386:x86-64 | head -n8
21:28:00 <zid> kernel.bin: file format binary
21:28:00 <zid> Disassembly of section .data:
21:28:00 <zid> 0: 7f 45 jg 0x47
21:28:00 <zid> 0000000000000000 <.data>:
21:29:00 <mjg> UNIX MOTHERF^W
21:29:00 <zid> chiselfuse: You can make it show you that fine
21:29:00 <heat> mjg are you team intel or team att
21:29:00 <zid> it's on the right click menu
21:29:00 <mjg> what kind of question is that
21:29:00 <mjg> team at&t
21:29:00 <mjg> intel syntax looks like roadkill
21:29:00 <heat> proper UNIX fan
21:30:00 <mjg> ate by a dog and vomitted back
21:30:00 <Mondenkind> go back to 1970
21:30:00 <heat> this is a xenix enjoyer if i've ever seen one
21:30:00 <zid> can also just do weird stuff like hooking python scripts up to hotkeys
21:30:00 <Mondenkind> boomer
21:30:00 <heat> x86 low level code copyright (c) Microsoft Corporation
21:30:00 <mjg> Mondenkind: i would if i could!
21:30:00 <chiselfuse> zid: i've looked carefully in right click options and haven't found anything that would show me the instruction without the analysis. can you tell me which option specifically?
21:30:00 <mjg> btw solaris has microsoft-copyrighted code somewhere
21:30:00 <mjg> :)
21:30:00 <heat> i know
21:30:00 <heat> they have deh aforementioned xenix code
21:31:00 <mjg> ye that's probably it
21:31:00 <heat> which i believe got to svr4, then sunos
21:31:00 <zid> I'll.. boot ida I guess
21:31:00 <zid> H
21:32:00 <zid> https://cdn.discordapp.com/attachments/417023075348119556/1259622993907159161/image.png?ex=668c5ad4&is=668b0954&hm=be120058cae3fda7b1c5fbc6735001c1b0b8e0e23c17e8330e7818a4ce206989&
21:32:00 <kof673> are we doing unix gripes? usleep(3) On the original BSD implementation, and in glibc before version 2.2.2, the return type of this function is void if it is not void, it can tell you it was interrupted, but not how much time remains??? POSIX.1-2008 removes the specification of usleep()
21:32:00 <zid> cmp [ebp+wins], 4 -> cmp dword ptr [ebp-12], 4
21:33:00 <zid> also at the top of the function is the stack frame with all the variables, wins -12
21:33:00 <chiselfuse> zid: can't do that with something like `call _printf`, i might be misremembering but i think there are instructions where it does more than just rename an absolute address and will still not allow you to do H
21:34:00 <heat> kof673, that's a BSD gripe
21:34:00 <heat> beating on BSD is like beating a dead worse
21:34:00 <heat> horse
21:34:00 <heat> worse horse really
21:34:00 <kof673> possibly, but glibc kept "compat"
21:35:00 <kof673> and posix also ate it up
21:35:00 <kof673> bsd may have started it :D
21:35:00 <heat> ofc, what was it supposed to do?
21:35:00 <zid> yea if it has symbols it will use them, it's an interactive decompiler thingy not a dumb assembly listing
21:35:00 <heat> they already broke compat on a bunch of symbols and they/we are paying for it
21:35:00 <zid> if you want one of those that's easily had
21:36:00 <zid> you can also just split the screen and auto-sync between other views, like the hex view you mentioned
21:36:00 <kof673> well posix ditched it and there is nanosleep() i guess now :D
21:36:00 <heat> GNU/POSIX basename and dirname are fun, pre-c99 glibc printf had some gnu extensions they had to whack conditionally for c99, with awful preprocessor hacks
21:37:00 <chiselfuse> i'm making a key binding that takes contents of primary selection and pop ups disassembly using dunst
21:37:00 <heat> the glibc ioctl signature is different from the old POSIX ioctl signature, and that's a pain point for musl (which is stubbornly pro-POSIX)
21:37:00 <zid> sounds good
21:40:00 <mjg> :D
21:41:00 <mjg> rolling with musl is pulling of a bsd mon
21:41:00 <heat> unironically bsd libc is probably pretty high quality
21:41:00 <mjg> 8D
21:42:00 <heat> i'm sure you can find all sorts of crap in there, don't eight D me
21:43:00 <heat> BUT it's probably mostly okay
21:43:00 <heat> *and* can static link
21:43:00 <mjg> mofo
21:43:00 <mjg> it's total shite
21:43:00 <mjg> the original string ops for example were written by someone who heard assembly exists
21:44:00 <heat> performance is not the main criteria for libc quality
21:44:00 <mjg> did yo usee that link where said users found out musl string ops were demolishing perf
21:44:00 <mjg> sad
21:45:00 <mjg> this was the same shit in freebsd before i sorted it out (mostly, still not OPTIMAL)
21:45:00 <mjg> it's not a matter of not saving some cycles here and there but actively fucking the perf
21:45:00 <mjg> the shite memcpy is the same as originally found in freebsd
21:46:00 <heat> my big problem with musl is not that it's slow, but that the people involved are entirely anti-pragmatism in any way
21:46:00 <mjg> this is probably big part of why it is slow
21:46:00 <heat> yes
21:47:00 <heat> musl is generally pretty high quality and correct, at the expense of code readability and performance
21:47:00 <heat> glibc throws you a heavily preprocessed 4000 printf you can barely read as C
21:48:00 <heat> all in all BSD libc is probably in a decent sweetspot between the two
21:56:00 <kof673> i have a freebsd 2.2.9 vm in qemu to run moss toolchain...and probably will keep it because getting old binutils and gcc to compile on modern systems...don't trust it...needs varargs.h too...in any case, pretty sure "su" just segfaults, you want to patch that mjg :D
21:56:00 <mjg> kof673: please update to a newer version
21:56:00 <mjg> :X
21:57:00 <heat> mjg, mofer here's a fun question
21:57:00 <heat> at what point is it worth it to move from O(n) algos to O(log n) or something
21:58:00 <heat> lets say O(n) is a linked list and O(log n) is a binary tree
21:58:00 <kof673> i was amazed the installer is basically the same, thought i would have to learn something
21:58:00 <mjg> heat: i don't think it's fun
21:59:00 <mjg> heat: by default you want something which does not blow up, so the log n thing
21:59:00 <mjg> heat: and only consider O(n) if you can show that for real-world n you get it is faster to not mess around
21:59:00 <mjg> but even then you need to gate the n
21:59:00 <heat> but the linked list will be empirically faster for small values of n no?
22:00:00 <mjg> for small values of n you should have an array
22:00:00 <mjg> and even that sucker can be log n'd
22:00:00 <mjg> this is basically "should i stab myself in the eye with a fork or a pencil" type of deal
22:00:00 <mjg> how about you don't
22:01:00 <heat> it's a perfectly valid question
22:02:00 <heat> freebsd 2.2.9 had a shit ton of linked lists and they were probably faster on that era's hardware than O(log n) BSTs
22:02:00 <heat> because the scale was smaller and the branch predictor was non-existent
22:03:00 <heat> like, using a linked list for the vm regions makes some sense if you consider that every process has like... 6 regions at most?
22:03:00 <mjg> i made a wild assumption you are talking today hardare
22:04:00 <mjg> anyhow
22:04:00 <mjg> i have to bail
22:04:00 <heat> same applies to today's hardware
22:04:00 <mjg> i leave you with this https://yosefk.com/blog/advantages-of-incompetent-management.html
22:04:00 <bslsk05> yosefk.com: Advantages of incompetent management
22:04:00 <mjg> i can flame it later
22:04:00 <mjg> have to afk for 40
22:05:00 <kof673> "please update" enterprise-quality answer
22:15:00 <geist> a really lovely series of freebsds is freebsd4
22:15:00 <geist> i think it went all the way up to 4.11 too
22:24:00 <heat> geist have you seen the gcc x86 inline asm condition code outputs
22:24:00 <heat> it's so hot
22:24:00 <geist> do you mean hot amazing or hot wtf?
22:24:00 <heat> hot amazing
22:25:00 <heat> int ccz; __asm__("dec %rax" : "=@ccz"(ccz));
22:25:00 <heat> basically =@ccCONDITION_CODE
22:25:00 <heat> it generates optimal sexy asm
22:25:00 <geist> oh neat. is that new?
22:25:00 <heat> gcc 6
22:26:00 <geist> ah good to know
22:26:00 <heat> iirc they added it for linux, cuz they used to use asm gotos for dec_and_test i believe
22:42:00 <kof673> moss actually has the void usleep() because it pulls from old freebsd for "libc" ... anyways lol good thing i made a define -DLNSST_USE_USLEEP_FUNCTION -DLNSST_USLEEP_RETURNS_VOID
22:42:00 * kof673 afk
22:54:00 <mjg> heat: so for small enough n which you guarantee to be small just use an array
22:54:00 <mjg> faster than ll's
22:55:00 <heat> yeah generally that's a good option
22:55:00 <mjg> and cheaper on memroy
22:55:00 <heat> C++ people are generally on the std::vector kool aid
22:55:00 <mjg> what is that internally
22:55:00 <mjg> ll?
22:55:00 <heat> no, realloc loop
22:55:00 <mjg> 8s
22:55:00 <mjg> what's the growth factor on that one
22:55:00 <heat> 2
22:55:00 <mjg> that's the sensible default
22:56:00 <heat> insert is amortized to O(1) basically
22:56:00 <heat> and that does remind me i need a rcu vector implementation
22:57:00 <heat> however fitting the rcu callback struct will be super messy wrt kmalloc buckets
22:57:00 <mjg> don't rcu callback it
22:57:00 <heat> kfree_rcu always needs a struct
22:58:00 <mjg> you can create a dedicated "this shit frees arrays" routine
22:58:00 <mjg> then the callback is implicit
22:58:00 <mjg> you store a number of the arrays in a magic array
22:58:00 <mjg> and always know how to tear them down
22:58:00 <heat> arrays all the way down
23:00:00 <heat> honestly i don't really see what you mean
23:00:00 <heat> it could be possible to pull off something weird in the slab allocator
23:02:00 <heat> wins are probably... not that big? it's doubtful that N * sizeof(T) will be a perfect 2^N anyway
23:02:00 <mjg> you collect them in something
23:02:00 <heat> well 2^M
23:02:00 <mjg> the currently rcu-freeable shit is all linked-listed no?
23:02:00 <heat> yes
23:02:00 <mjg> instead you create a dedicated array for fuckers
23:02:00 <heat> yeah but you need to allocate to free, no? if that's what you're getting at
23:02:00 <mjg> it does run into a problem where the array is of finite capacity tho
23:02:00 <mjg> allcoate what
23:03:00 <heat> the array
23:03:00 <heat> finite doesn't work
23:03:00 <mjg> you do realize it's all finite
23:03:00 <mjg> :d
23:03:00 <heat> you can't just "flush" the array due to it being an RCU free
23:03:00 <mjg> and i mean pretty tight
23:03:00 <nikolar> does rcu always make sense (for reader heavy workloads)
23:04:00 <nikolar> like is rcu-ing the process table fine
23:04:00 <mjg> heat: no, but if it is has a big enough practical size
23:04:00 <heat> yes
23:04:00 <mjg> heat: you could wait for the grace period on overflow
23:04:00 <mjg> as an emergency measure
23:04:00 <mjg> nikolar: that's a misleading question
23:04:00 <heat> hmm that's a decent idea yeah
23:04:00 <nikolapdp> mjg: got anything to add to that
23:04:00 <mjg> nikolar: it's always faster to avoid stores to shared areas
23:05:00 <mjg> which rcu definitely facilitates
23:05:00 <mjg> but is not the only way to do it
23:05:00 <heat> SHARDING
23:05:00 <mjg> another classic is to make the struct copy-on-write
23:05:00 <mjg> et voila, no fucken' stores and no rcu either
23:05:00 <nikolapdp> true
23:05:00 <heat> the linux pid table is fully rcu'd
23:06:00 <heat> i intend to do that on onyx too
23:06:00 <mjg> meh
23:06:00 <heat> the rest *is not* which runs into scalability issuen
23:06:00 <mjg> this particular aspect is not that great
23:06:00 <nikolapdp> can you think of any structure that you definitely shouldn't rcu
23:07:00 <mjg> i can think of cases where rcu usage would be a waste of time
23:07:00 <heat> write mostly!
23:07:00 <mjg> but rcu is employed for unrelated reasons
23:07:00 <nikolapdp> i am talking about correctness mostly, not performance
23:07:00 <mjg> i don't think that's a valid question
23:07:00 <mjg> in that case
23:07:00 <heat> "employing" rcu does not really affect correctness unless your usage is wrong or iffy
23:08:00 <nikolapdp> well readers could have a slitghtly out of date data, no?
23:08:00 <heat> rcu read lock is basically an existence guarantee, nothing more
23:08:00 <heat> nikolapdp, you can use seq counts, flags for that
23:08:00 <mjg> readers always have out of date data
23:09:00 <mjg> suppose you have a read-write lock and are racing against a writer
23:09:00 <mjg> the writer now waits for you to finish
23:09:00 <mjg> but the writer wants to mess with the state
23:09:00 <nikolapdp> right, guess so
23:09:00 <mjg> which it will do immediately after you leave
23:09:00 <mjg> basically the state is considered stale the cycle you drop the lock
23:09:00 <heat> i.e a popular RCU pattern to use in tables, when you need to get some item and up-ref it is: again: struct S *s = rcu_dereference(table[i]); if (!ref_not_zero(&s->ref)) goto again;
23:10:00 <heat> where ref_not_zero is a cmpxchg
23:11:00 <nikolapdp> interesting
23:11:00 <heat> basically guarantees you're not getting a stale, dead object
23:11:00 <heat> rcu is used there as an existence guarantee (this cmpxchg will definitely not fault)
23:12:00 <nikolapdp> makes sense
23:21:00 <mjg> for (i = 0; i < n; n++) {
23:21:00 <mjg> who can spot the bug
23:22:00 <nikolar> lel
23:22:00 <heat> i++
23:22:00 <nikolar> n++
23:22:00 <mjg> both wrong
23:22:00 <heat> in C++ that's UB
23:22:00 <mjg> delete
23:22:00 <nikolapdp> we don't do c++ here heat
23:22:00 <heat> actually we do
23:22:00 <nikolapdp> no, you do
23:22:00 <heat> wrong
23:22:00 <heat> the most successful hobby kernels are written in C++
23:23:00 <nikolapdp> onyx isn't the most successful kernel
23:23:00 <mjg> openbsd is in c
23:23:00 <heat> notice the s
23:23:00 <nikolapdp> mjg what was the bug then
23:24:00 <mjg> i am jerking about the fix
23:25:00 <mjg> the fix is to delte the loop
23:25:00 <mjg> anyhow i'm off
23:25:00 <mjg> cheerzen
23:25:00 <nikolapdp> bye
23:25:00 <heat> actually i was slightly wrong
23:25:00 <heat> that loop may or may not be UB in both C and C++
23:25:00 <Mondenkind> it's ub in c too
23:25:00 <Mondenkind> or at least something ub-like
23:25:00 <heat> yeah depends if n is signed
23:26:00 <nikolapdp> are you referring to the overflow behaviour
23:26:00 <heat> yes
23:26:00 <nikolapdp> is the loop ub then, or just the increment
23:26:00 <heat> if n is signed, it's UB on both. if n is unsigned, it's UB in C++ only
23:26:00 <Mondenkind> oh no i wasn't talking about that
23:26:00 <Mondenkind> it's infinite loop ub
23:26:00 <Mondenkind> :)
23:26:00 <nikolapdp> because if it's just the increment that it will emit inc %rax and you'll be fine
23:26:00 <nikolapdp> in c
23:26:00 <Matt|home> o\
23:26:00 <heat> it's still UB
23:27:00 <heat> oh i had a great quote for this moment
23:27:00 <Mondenkind> wait hmm. if it's unsigned then it's infinite loop ub. if signed then overflow ub
23:27:00 <Matt|home> very quick, very dirty answer i don't care if it's super accurate or if there are exceptions or whatever, just want a general yes/no: c++ for kernel, bad/good now?
23:27:00 <heat> <heat> kiss the girls you didn't ask while arguing UB on IRC
23:27:00 <heat> <heat> didn't kiss*
23:27:00 <Matt|home> for modern OS
23:27:00 <nikolapdp> Matt|home: bad
23:27:00 <geist> good
23:27:00 <Matt|home> luls
23:27:00 <Mondenkind> i agree with both answers
23:27:00 <nikolapdp> lel
23:27:00 <heat> ignore the C++ hater
23:27:00 <nikolapdp> ignore heat
23:27:00 <heat> it's good if you like C++, it's bad if you don't
23:27:00 <Mondenkind> ignore both of them
23:27:00 <zid> signed overflow ub is funny, it's designed so that you can just do inc rax without having to worry about sign-mag systems giving a different result on overflow, but the compiler loves seeing it and going OOH THIS IS MY TIME TO SHINE
23:27:00 <Matt|home> did not wanna start a debate :D i was just curious on a whim
23:28:00 <heat> there's really no debate, it's perfectly adequate if you like the language
23:28:00 <nikolapdp> zid that's what i was referring to
23:28:00 <zid> exec("nethack") time
23:28:00 <Matt|home> copy that
23:28:00 <heat> it's still perfectly adequate if you don't like it, but then you just don't use it
23:28:00 <Mondenkind> 'is x good or bad' is not a useful question in general
23:28:00 <nikolapdp> indeed
23:28:00 <Mondenkind> (that said uhhhh c++ is definitely bad)
23:28:00 <nikolapdp> there we go
23:28:00 <Matt|home> well, the reason i ask is cuz i was under the impression that C was primarily used for kernel development cuz of it's speed and compactness more than anything
23:28:00 <heat> and tradition
23:29:00 <Matt|home> so idk how much overhead using C++ would bring in terms of performance
23:29:00 <heat> tradition more than any other reason
23:29:00 <heat> like these kernels are ooooooooooooooooold
23:29:00 <geist> well, it's not a great question, but if you get smoething universally non polarizing that's a good direction
23:29:00 <geist> like 'kernel in COBOL? Y/N'
23:29:00 <geist> i doubt a lot of folks would seriously say Y
23:29:00 <heat> obviously yes
23:29:00 <kof673> surely KERNEL IN COBOL? Y/N
23:29:00 <kof673> (i do not know, but i would bet on it)
23:29:00 <Matt|home> lemme rephrase the question then to be more technically accurate
23:30:00 <nikolapdp> was there a kernel in cobol?
23:30:00 <nikolapdp> maybe something from ibm lol
23:30:00 <kof673> it was a capitalization joke :/
23:30:00 <kof673> yes, probably :D
23:30:00 <nikolapdp> kek
23:30:00 <geist> fortran maybe. lots of systems stuff was written in various dialects of fortran
23:30:00 <Matt|home> are there significant differences in performance between modern languages for OS/kernel development use? e.g. if i wrote a full modern desktop oeprating system in C would it be objectively faster than one written in C++ or python or C# or any other language
23:30:00 <Matt|home> or not even by milliseconds in terms of real world usage
23:30:00 <geist> but really early kernels up through the 70s were almost certainly written in asm or some macro assembler like language
23:30:00 <heat> Matt|home, it depends
23:31:00 <nikolapdp> well if you use inheritance, then c++ is going to be slower
23:31:00 <heat> C and C++ will be very similar
23:31:00 <geist> Matt|home: not really. no. but then what you do with the language matters
23:31:00 <nikolapdp> due to virtual dispatch etc
23:31:00 <heat> nikolapdp, what?
23:31:00 <Matt|home> okay so im getting a lot of "it really depends". understood
23:31:00 <nikolapdp> yes, it really depends
23:31:00 <heat> if you're using virtual dispatch in C++ you'd use a function pointer in C
23:31:00 <heat> it's really the same thing
23:31:00 <geist> the language itself doesn't force you do do anything you dont want to do in C, but it *tends* to have you write more inefficient code for better code reuse, testability, etc
23:32:00 <geist> and when the code base gets large enough that sort of stuff tends to matter more
23:32:00 <Matt|home> i guess im operating under the incorrection assumption that some languages are more efficient than others
23:32:00 <geist> it's hard to imagine writing any large codebase in C nowadays. and then you can debate what 'large' is
23:32:00 <heat> that's not entirely incorrect
23:32:00 <heat> like C vs java is a pretty easy dilemma
23:32:00 <geist> right, but... C++ is not really any more inefficient per se than C
23:32:00 <geist> it just lets you build more abstract concepts that may not be as straight line optimized as you can hand write in C
23:33:00 <kof673> i would bet if no cobol kernel, probably some app that was the main thing running :D
23:33:00 <nikolapdp> oh that definitely
23:33:00 <heat> C vs C++, or C vs rust, or C++ vs rust, or if you squint really hard Rust vs Go... yeah it's on a knife's edge
23:33:00 <geist> think of C as sort of an assembly of C++. so you *could* tend to write more directly tuned things, but takes more time, etc
23:33:00 <Matt|home> "C
23:33:00 <Matt|home> Windows NT is written in C and C++, with a very small amount written in assembly language. C is mostly used for the kernel code while C++ is mostly used for user-mode code. Assembly language is avoided where possible because it would impede portability."
23:33:00 <Mondenkind> go not really lol
23:33:00 <heat> it has been done
23:33:00 <Matt|home> mkay
23:33:00 <Mondenkind> java perf wise i would expect to walk all over go
23:33:00 <geist> keep in mind most modern production kernels were started in the 80s or 90s. and at the time the equation was definitely different
23:34:00 <geist> C was the defacto language
23:34:00 <heat> see the mit pdos go unix kernel
23:34:00 <nikolapdp> i assume you can write go in a way that minimizes gc, in which case it's going to get close to the rest
23:34:00 <Matt|home> so it's still well within the realm of reasonableness to write a full modern kernel in C
23:34:00 <nikolapdp> absolutely
23:34:00 <heat> uhhh define reasonableness
23:34:00 <Mondenkind> and java vs c probably O(10-20%) at worst, and mostly because of the way the language encourages you to write code
23:34:00 <geist> sure, mine have always been in C as well, but they're older and smaller
23:34:00 <Matt|home> i mean i just read from the wikipedia page, the NT kernel is pretty much written in straight C
23:34:00 <heat> that is wrong
23:34:00 <Matt|home> and that's a big kernel
23:34:00 <nikolapdp> was
23:34:00 <geist> nowadays i'd 100% start in C++ from the get go. but then i generally would be careful what part of the language to use where, and would be okay breaking the rules for speed or smallness, where appropriate
23:34:00 <nikolapdp> we aren't really sure now
23:35:00 <Matt|home> https://en.wikipedia.org/wiki/Windows_NT <-- ?
23:35:00 <heat> large swaths of NT are in C++, small swaths of NT are in rust now
23:35:00 <nikolapdp> Matt|home: i am referring to the ratio, we don't know how much c there is compared to c++ nowadays
23:35:00 <geist> yah but NT kernel is probably still mostly C. or at least C with msft's extensions
23:35:00 <zid> I'm not convinced that approach scales for massive open source projects, geist
23:35:00 <nikolapdp> for earlier windowses it was almost all c, but who know
23:35:00 <mjg> why would you c++ a new project
23:36:00 <Matt|home> https://learn.microsoft.com/en-us/previous-versions/cc767881(v=technet.10)
23:36:00 <bslsk05> learn.microsoft.com: Lesson 2 - Windows NT System Overview | Microsoft Learn
23:36:00 <nikolapdp> indeed mjg
23:36:00 <geist> zid: very possible. depends a lot on the invididuals involved, how much hand holding you want, etc
23:36:00 <geist> but then large open source projects are *hard*
23:36:00 <zid> There's going to be a *lot* of people with a *lot* of opinions on what the rules are, even if you don't accept it
23:36:00 <zid> there's going to be a lot of talking
23:36:00 <geist> sure, but that's a human problem, not a technical problem. if you want to make technical decisions around humans thats a hard call to make
23:36:00 <geist> and very very project specific
23:36:00 <heat> mjg, when you can't rust yet
23:37:00 <mjg> where is that
23:37:00 <Matt|home> https://learn.microsoft.com/en-us/shows/one-dev-minute/one-dev-question-raymond-chen-programming-language-windows-written-in <--- theeeeere we go, found it
23:37:00 <bslsk05> learn.microsoft.com: One Dev Question with Raymond Chen - What Programming Language is Windows Written In? | Microsoft Learn
23:37:00 <heat> mjg, where is what
23:37:00 <Matt|home> "most of the kernel code is still in C"
23:37:00 <mjg> rust which you can't use
23:37:00 <zid> yea technically C++ can be used to great effect, it's all the non-technical things I find fault with mainly
23:37:00 <zid> safe subsets, etc
23:38:00 <nikolapdp> (which is c :P)
23:38:00 <heat> it's not rust which you can't use, it's people that can't use rust (because they don't know it)
23:38:00 <zid> I prefer the language to just be 'it's this, do this'
23:38:00 <geist> indeed. you need to be careful about defining it
23:38:00 <zid> save people from themselves
23:38:00 <Matt|home> main reason they're citing keepiung it in C is apparently because of C++'s auto generation
23:38:00 <nikolapdp> auto generation?
23:38:00 <zid> how many null pointers is C++ up to now? :P
23:39:00 <geist> i can tell you as a person that works on a kernel written in C++, it works quite well, but indeed you need to define the appropriate subsets
23:39:00 <heat> mjg, like, objectively there's very little reason to do a C/C++ project in !rust unless you 1) really hate the language 2) don't know it 3) fanboy for C's
23:39:00 <geist> but in general its okay, and very powerful
23:39:00 <Matt|home> "C++ does a lot of auto code generation or data auto generation and you don't get a lot of control over where that goes. [bklah blah] over where in memory the vtable goes and so blah blah"
23:39:00 <Matt|home> that's their cited reasons
23:39:00 <zid> Maybe if we really were in a "linux is C++" universe
23:39:00 <heat> bullshit
23:39:00 <zid> the push hook linters would be super great
23:39:00 <zid> and tell you off for doing a bunch of things
23:39:00 <geist> NT does have pagable kernel memory, which i'm sure they regret now. that might cause problems there
23:39:00 <mjg> heat: well i am advocating for rust over c or c++ for a new proj
23:40:00 <geist> also there's the whole loadable driver model, which causes C++ ABI issues
23:40:00 <mjg> pageable memory is something they can stop doing
23:40:00 <mjg> i mean what is going to break if they drop it
23:40:00 <geist> yah dunno if they removed that or not, but if they did i bet it was only fairly recent (last 10 years or so) and then you have these bazillion lines of C code, worth converting? probably not
23:41:00 <heat> mjg, i know, and that's sensible as long as you don't step into really weird territory that's poorly explored. like RCU. or integration with C++ code. or even integration with C is a bit of a pain
23:41:00 <heat> or you fit into one of my 3 points
23:41:00 <mjg> anyhow now i'm really off, cheers
23:41:00 <geist> but the neat thing about C++ for kernel code is you can always write basicaly C code in C++ if you want, and just dip your toes a bit into something
23:42:00 <geist> add some RAII bits here and there (that's hecka convenient). or some simple structs with helper methods on it, etc
23:42:00 <heat> there are bazillions of NT code in C++ mainly because AFAIK it's the main language used for driver development there
23:42:00 <nikolapdp> when heat does that he calls it c
23:42:00 <geist> nothing in C++ requires that you go Full Java and put everything in a class or whatnot
23:42:00 <geist> but i've also seen a lot of MSFT folks call C C++ and C++ C, they sort of talk like it's the same language
23:42:00 <geist> so you have to be a bit careful
23:43:00 <heat> subscribe
23:43:00 <heat> that's my brand of c++
23:44:00 <heat> but really when microsoft did dtrace for windows they had to add some small tidbits of C++ support
23:44:00 <nikolapdp> geist: re david plumber
23:44:00 <geist> right
23:44:00 <heat> it is entirely likely some non-trivial bits are written in C++
23:44:00 <geist> yah, totally possible you can use C++ in kernel drivers but the driver API is almost certainly C
23:44:00 <geist> but that's also totally doable
23:45:00 <heat> yep
23:45:00 <geist> thats where yo uget into the 'what is the kernel' thing when talking about modular kernels like NT
23:45:00 <geist> most likely it's not in one codebase at all, lots of separate repos within msft, etc
23:45:00 <heat> C API/ABI with C++ code internally is an entirely sensible approach that even userspace projects do
23:45:00 <geist> yah that's what i'm generally doing with LK nowadays. writing new things in C++ but keeping the C api between modules
23:46:00 <nikolapdp> didn't ms make a lot of git contributions because they are basically working in a massive monorepo for windows
23:46:00 <heat> i don't think windows uses git
23:46:00 <geist> they definitely had their own thing for a while, from what i heard, but i think they switched relatively recently to something new
23:46:00 <nikolapdp> there was a presentation by one of the important guys at github that mentioned that factoid
23:46:00 <nikolapdp> i think
23:47:00 <geist> but a monorepo doesn't mean you have everything under one directory
23:47:00 <heat> geist, i've been scaling back the little C++-yness i had and even writing full functionality in C
23:47:00 <heat> mostly because i'd like to use the infra around current kernels, and also to prepare eventual rust experiments
23:47:00 <geist> word; what i've generally found is drivers are really lovely C++ places
23:47:00 <geist> they're basically leaf nodes, basically object oriented anyway, since it's a drier working on an instance of a device
23:48:00 <heat> yeah totally
23:48:00 <heat> like who cares there, just don't have a struct class and we're all fine
23:48:00 <geist> things that are large singletons dont really match the C++ object layer as much
23:49:00 <heat> my big problem is that lots of great stuff doesn't grok C++, dtrace doesn't, bpftrace doesn't
23:49:00 <geist> yah, super long ass symbols really annoying for tracing
23:49:00 <heat> which if you'd like to integrate those great tools, it screws you up
23:49:00 <heat> oh struct randomization doesn't too!
23:49:00 <nikolapdp> struct randomization?
23:50:00 <heat> yes
23:50:00 <geist> forced structure layout, mostly due to inheritance, in C++ is one of the worst parts that you can't easily work aroun
23:50:00 <heat> it's a gcc plugin/clang feature that randomizes member placement around the struct
23:50:00 <geist> you can't tweak the layout of a thing to properly pack the instant you use inheritance, beacuse the superclass *has* to go first, etc
23:50:00 <nikolapdp> heat: for debugging purposes i imagine?
23:51:00 <geist> ad if yo uhave a big singleton object (TheScheduler, etc) you can't do things like force variables into particular sections, etc
23:51:00 <kof673> "security" young nikola
23:51:00 <nikolapdp> struct randomization, really?
23:51:00 <heat> security
23:51:00 <kof673> someone mentioned it here a few months ago is only reason i recall
23:52:00 <heat> it's entirely sensible
23:52:00 <nikolapdp> interesting
23:52:00 <heat> if the attacker doesn't know the seed, its exploitation methods are limited
23:52:00 <nikolapdp> how often does exploit rely on struct member ordering though
23:53:00 <geist> lots
23:53:00 <zid> You'd be surprised
23:53:00 <geist> any buffer overrun style thing is mostly about trying to tweak something in a neighboring data structure
23:53:00 <zid> C++ is actually super exploitable compared to C because of all the function pointers floating around in data structures
23:53:00 <geist> indeed, you can i guess replace the vtable and point it at your own thing
23:53:00 <zid> given that we compile everything with aslr and stuff, what tends to be a very reliable attack is things like use after free, dangling pointers etc, letting you create fake instances of structures
23:54:00 <zid> n^x, relro, etc
23:54:00 <zid> all protect C but do very little to protect the main attack on C++
23:54:00 <zid> You need the CET crap from windows to stop it
23:55:00 <nikolapdp> what's CET
23:55:00 <zid> function pointer authentication, basically
23:55:00 <zid> you have to have a special opcode embedded anywhere a call instruction could land else it blows up on you
23:56:00 <zid> to stop you doing things like jumping over the `if` in if(admin) do_special_thing();
23:56:00 <zid> with a corrupted function pointer
23:56:00 <nikolapdp> oh right, those are the weird instructions at the start of functions
23:56:00 <nikolapdp> i remember
23:56:00 <zid> there's also some bitmap shit
23:56:00 <zid> that makes it CET and not just intel whatever
23:56:00 <zid> shadow stacks
23:57:00 <nikolapdp> i forget, are there hardware shadow stacks on x86
23:57:00 <zid> CET is controlflow enforcement technology
23:57:00 <zid> yes but they suck, afaik
23:57:00 <zid> so CET is mostly software stuff
23:57:00 <nikolapdp> interesting
23:57:00 <geist> yah we use shadow stacks on x86 in fuchsia, and its not terribly cheap
23:57:00 <adder> heat, sure, how does this look? https://termbin.com/6byn
23:57:00 <geist> for ARM we use shadow call stacks, which is somewhat more efficient, but not really feasible on x86
23:58:00 <nikolapdp> geist, software shadow stacks i assume, on x86
23:58:00 <geist> yeah
23:58:00 <zid> It's crazy slow and very 'on the compiler' to implement, like compiling your code such that vtables look themselves up in a table to make sure they contain valid function pointers
23:58:00 <nikolapdp> ah yuck
23:58:00 <zid> or against a big bitmap of valid landing targets
23:58:00 <nikolapdp> geist, arm has hardware shadow stacks too
23:58:00 <geist> basically the shadow stack is a serarpate oe stored hanging off a fs: pointer that holds any local data that is in any way gettable by a pointer
23:58:00 <heat> adder, haha found your bug
23:58:00 <adder> no shit? :)
23:59:00 <zid> I think that big bitmap code fucking exploded in one of those windows internals blogs
23:59:00 <heat> you have interrupts on without remapping the PIC
23:59:00 <geist> so the compiler figures out where data goes
23:59:00 <heat> you're getting an IRQ at vector 8 (exception with error code)
23:59:00 <zid> '800 cores and chrome is slow' or 'compiling chrome takes 47 days on windows' one of those blog posts
23:59:00 <heat> therefore stack gets fucked
23:59:00 <nikolapdp> lel
23:59:00 <heat> e=0204 looks like iret is trying to load your eflags as a segment register