<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
<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
<nikolar>
you can
<nikolar>
especially if you don't care about other cores yet
<adder>
ok, that's great
<adder>
thanks, nikolar
<nikolar>
no problem
goliath has quit [Quit: SIGSEGV]
thesock has quit [Remote host closed the connection]
gcoakes has joined #osdev
HappyCoder314_ has joined #osdev
HappyCoder314_ has left #osdev [#osdev]
jjuran_ has joined #osdev
getz- has joined #osdev
zid` has joined #osdev
rom4ik1 has joined #osdev
adder_ has joined #osdev
xvmt_ has joined #osdev
basil0 has joined #osdev
lain`_ has joined #osdev
tom5760_ has joined #osdev
baraq_ has joined #osdev
yuiyukihira_ has joined #osdev
ddevault_ has joined #osdev
xtex_ has joined #osdev
noeontheend_ has joined #osdev
tommybomb_ has joined #osdev
sm2n_ has joined #osdev
exec64_ has joined #osdev
ursa-major_ has joined #osdev
alethkit_ has joined #osdev
torresjrjr_ has joined #osdev
puck__ has joined #osdev
<zid`>
liberapls
basil has quit [Read error: Connection reset by peer]
exec64 has quit [Read error: Connection reset by peer]
basil0 is now known as basil
rom4ik has quit [Read error: Connection reset by peer]
rom4ik1 is now known as rom4ik
adder has quit [Read error: Connection reset by peer]
sm2n has quit [Read error: Connection reset by peer]
noeontheend has quit [Read error: Connection reset by peer]
alethkit has quit [Read error: Connection reset by peer]
ddevault has quit [Read error: Connection reset by peer]
torresjrjr has quit [Read error: Connection reset by peer]
Opus has quit [Remote host closed the connection]
xtex has quit [Ping timeout: 268 seconds]
ddevault_ is now known as ddevault
yuiyukihira has quit [Read error: Connection reset by peer]
baraq has quit [Read error: Connection reset by peer]
lh has quit [Read error: Connection reset by peer]
ursa-major has quit [Read error: Connection reset by peer]
tom5760 has quit [Read error: Connection reset by peer]
yuiyukihira_ is now known as yuiyukihira
baraq_ is now known as baraq
listentolist has quit [Read error: Connection reset by peer]
tom5760_ is now known as tom5760
tommybomb has quit [Read error: Connection reset by peer]
tommybomb_ is now known as tommybomb
noeontheend_ is now known as noeontheend
xtex_ is now known as xtex
exec64_ is now known as exec64
xenos1984 has quit [Ping timeout: 268 seconds]
zid has quit [Ping timeout: 268 seconds]
jjuran has quit [Ping timeout: 268 seconds]
jjuran_ is now known as jjuran
Opus has joined #osdev
alethkit_ is now known as alethkit
lain` has quit [Ping timeout: 268 seconds]
xvmt has quit [Ping timeout: 268 seconds]
frkazoid333 has quit [Ping timeout: 268 seconds]
pdziepak has quit [Ping timeout: 268 seconds]
xvmt_ is now known as xvmt
lain`_ is now known as lain`
torresjrjr_ is now known as torresjrjr
pdziepak has joined #osdev
xenos1984 has joined #osdev
puck has quit [Ping timeout: 268 seconds]
getz has quit [Ping timeout: 268 seconds]
puck__ is now known as puck
sm2n_ is now known as sm2n
duckworld has quit [Ping timeout: 264 seconds]
ursa-major_ is now known as ursa-major
<nikolapdp>
libera is liberaing
thesock has joined #osdev
duckworld has joined #osdev
thesock has quit [Client Quit]
<adder_>
does it matter if I first load idt then remap pic?
adder_ is now known as adder
<adder>
getting a panic somehow
<heat>
not if you keep interrupts off
<adder>
they are off, in the sense that I didn't sti
<adder>
it's just a panic out of nowhere, not even in the path that could trigger it
<zid`>
..panic?
<zid`>
cpu's don't have panics, do you mean #GP?
housemate has joined #osdev
<adder>
I meant the function in my code that's supposed to panic, runs
<adder>
like nothing in the path calls it
<zid`>
is it next in the binary and you fell through to it? :P
<zid`>
corrupted your stack?
<adder>
could be
<zid`>
qemu can instruction trace
<zid`>
if you absolutely need it
<adder>
you know what was it
X-Scale has quit [Quit: Client closed]
<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
<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
<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.
HappyCoder314 has joined #osdev
HappyCoder314 has left #osdev [#osdev]
HappyCoder314 has joined #osdev
HappyCoder314 has left #osdev [#osdev]
<zid`>
identity mapping your kernel is weird
<adder>
so I'm getting an exception for some reason
<adder>
can't make sense of all this output in qemu
<adder>
a gpe
rustyy has quit [Ping timeout: 246 seconds]
rustyy has joined #osdev
Abaddon has quit [Ping timeout: 268 seconds]
jeaye has joined #osdev
netbsduser has joined #osdev
netbsduser has quit [Ping timeout: 264 seconds]
<geist>
a gpf? what was the error code
<geist>
generally speaking the program counter at the place it GPFed and the error code is enough to figure it out
<geist>
or at least figure out what class of problems it is
<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
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #osdev
<adder>
I seem to have narrowed it down to loading the gdt somehow wrongly... qemu says GDT= 00000000 00000000
<zid`>
what about GDTR
<adder>
I'm calling gdt_flush, and then from assembly, lgdt gdt_ptr, where gdt_ptr is struct u16 u32 packed
<adder>
then a ljmp
<adder>
this code worked just fine but for some reason it doesn't now
DrPatater has quit [Quit: Explodes into a thousand pieces]
<zid`>
what about GDTR
<adder>
ah you mean in qemu?
<zid`>
yes in qemu
<zid`>
it was in response to "qemu says GDT="
<adder>
I don't see gdtr the way I run qemu (-d int)
<zid`>
ah yea it's just called GDT but means the GDTR
<zid`>
oops
<zid`>
yea it shouldn't be 0 0 unless something messed up
<zid`>
might be worth putting a breakpoint on the lgdt [blah] line and checking it takes correctly
<adder>
thanks, I guess I'll try that
<adder>
let me first try to bisect the thing and try and see where it went wrong
vdamewood has joined #osdev
housemate has joined #osdev
GeDaMo has joined #osdev
<adder>
so, nothing was wrong... what kazinsal said is even the most likely :)
<adder>
so I want to capture keyboard input, but I'm not sure if that makes sense before I transfer control to the kernel?
housemate has quit [Quit: "I saw it in a TikTok video and thought that it was the smartest answer ever" ~AnonOps Radio [LOL]]
<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
<zid`>
why not just put an infinite jump in, then you don't have to play silly games with interrupts working in certain ways
<adder>
so I'd need to move on now and then get back to interrupts later once the kernel has the control
<zid`>
and put in a "you shouldn't be able to get here" printf or something too for good luck
<zid`>
this is development code, do things to make your life easier
<zid`>
once it works you can tidy it
<adder>
yeah no probs
<adder>
jump from I assume asm?
<adder>
to where?
valshaped7424880 has quit [Ping timeout: 264 seconds]
<adder>
or did you mean I should put in place a fake kernel and then jump there?
<adder>
this strikes me as a good idea
<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
<geist>
`info registers` should show it
<adder>
sorry, did zid mean infinite loop or jump infinitely forward?
<adder>
gdt looks just fine once I don't fall through from noreturn
<zid`>
int noreturn this_function_you_keep_talking_about(){ .... while(1); }
<zid`>
There, now it can't fall through, considering you've added this bug.. 4 times?
<zid`>
you can test removing it later on, once it all works as expected
<zid`>
it's just making your debugging experience very difficult not doing it
<adder>
ah okay :)
<adder>
0xd again
<adder>
this time gdt looks alright
bauen1_ has joined #osdev
<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
bauen1 has quit [Ping timeout: 268 seconds]
housemate has joined #osdev
housemate has quit [Quit: "I saw it in a TikTok video and thought that it was the smartest answer ever" ~AnonOps Radio [LOL]]
vdamewood has quit [Quit: Life beckons]
Left_Turn has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 256 seconds]
getz- is now known as getz
Matt|home has quit [Read error: Connection reset by peer]
Left_Turn has joined #osdev
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #osdev
Turn_Left has quit [Ping timeout: 256 seconds]
gog has joined #osdev
spare has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 260 seconds]
spare has quit [Remote host closed the connection]
DrPatater has joined #osdev
housemate has joined #osdev
housemate has quit [Remote host closed the connection]
housemate has joined #osdev
vai has joined #osdev
X-Scale has joined #osdev
heat has joined #osdev
<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
<kof673>
just put a little ascii art miniboss head at these parts of the code :D
<mjg>
quake?
<mjg>
where
<kof673>
i don't know, was trying to find the duke 3d thing...that came up..can't be bothered...
<bslsk05>
'Quake | You're not supposed to be here achievement | Tur Torment Secret achievement' by Dream's Guides (00:01:57)
<mjg>
this is defo not part of the base game
<mjg>
i mean the map itself is from one of the mission packs
<kof673>
it may very well be some 80's movie quote
<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
housemate has quit [Ping timeout: 268 seconds]
op has joined #osdev
X-Scale has quit [Ping timeout: 250 seconds]
vai has quit [Ping timeout: 268 seconds]
goliath has joined #osdev
rustyy has quit [Quit: leaving]
Starfoxxes has joined #osdev
rustyy has joined #osdev
op has quit [Remote host closed the connection]
housemate has joined #osdev
<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
<adder>
I should note that my gdt only contains 5 items, null descriptor, plus two code/data segments for kernel and user (no tss)
housemate has quit [Quit: "I saw it in a TikTok video and thought that it was the smartest answer ever" ~AnonOps Radio [LOL]]
housemate has joined #osdev
Turn_Left has quit [Remote host closed the connection]
Turn_Left has joined #osdev
mubluekoor has quit [Ping timeout: 272 seconds]
<gog>
adder: are you using gdb
<gog>
and do you have a GPF handler in your IDT?
<gog>
alternatively, you can add -d int to qemu and you can find the contributory faults if there are any
<gog>
because if an interrupt is happening with no corresponding entry in the IDT, it'll #GP
meisaka has quit [Ping timeout: 260 seconds]
<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)
<adder>
I believe I have reserved 32-256 correctly in the idt
<heat>
what's the error code, what's the IP
<heat>
what instruction is GPF'ing?
<adder>
uh how can I check?
<heat>
get the IP, disassemble that address
<adder>
0x000000000010275b: iret
<heat>
what's the error code?
<adder>
int_err_code seems to be 512
<adder>
(I printed this out, lmk if there's a better way to check)
<heat>
sounds like your stack is borked and you're iret'ing with bad state
<heat>
namely either ss or cs are 512
<adder>
ok, thanks for the hint
<adder>
let's see
m3a has joined #osdev
Turn_Left has quit [Ping timeout: 260 seconds]
gsekulski has joined #osdev
housemate has quit [Quit: "I saw it in a TikTok video and thought that it was the smartest answer ever" ~AnonOps Radio [LOL]]
Turn_Left has joined #osdev
<adder>
so.. seems like I'm seeing irq8
op has joined #osdev
<adder>
I try to eoi it but that's the first and the last of what I see
Turn_Left has quit [Ping timeout: 252 seconds]
<adder>
need to get some sleep, thanks all
Turn_Left has joined #osdev
Turn_Left has quit [Remote host closed the connection]
Turn_Left has joined #osdev
op has quit [Remote host closed the connection]
Turn_Left has quit [Remote host closed the connection]
Turn_Left has joined #osdev
mubluekoor has joined #osdev
elttil has joined #osdev
frkzoid has joined #osdev
<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
<elttil>
s go out according to netlog but gets no incoming packet.
<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
<nikolapdp>
you aren't, as long as you delete it later
<zid`>
do I have to?
<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
MrCryo has joined #osdev
<geist>
well maybe not so uc breaks qemu but causes you to get out of sync such that you'll receive no more packets
<elttil>
well that does not appear to be the case since qemu does not write stuff to the netlog
<nikolapdp>
yes
<geist>
true though maybe it only writes it to the log if its succesfully delivered to the nic
<geist>
and if the nic is overflowed or something it might drop the packet pre-netlog
<heat>
send a bug report to qemu-devel
<heat>
see what they say
<heat>
even if 9.0.1 works properly, cuz they'll probably want to backport the fix anyway
mavhq has joined #osdev
<zid`>
the rtl8139 code does a lot of DPRINTF in the recv path at least
<zid`>
but once it gets past the receiver enabled etc checks it's pretty brainlessly just writing stuff then triggering the irq
<zid`>
so imo if a packet shows up at all, it doesn't look like it can wedge
<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
<zid`>
I wonder if it's just that the socket got disconnected somewhere inside qemu or something, personally
Bonstra has quit [Quit: Pouf c'est tout !]
Bonstra has joined #osdev
xenos1984 has joined #osdev
spenc has joined #osdev
<elttil>
Well after having compiled QEMU version 9.0.1 and testing with that it appears to be working just fine.
<elttil>
First time it was not my fault :D
<heat>
maybe bisect and report upstream if you can
<heat>
the stable distro people probably want to apply that patch
<heat>
also ROLLING RELEASE WINS AGAIN
<heat>
i like life experiences that reinforce my views
<Ermine>
need to set up distcc
<nikolapdp>
rolling release wins every time heat
<nikolapdp>
Ermine what for
<nikolapdp>
i need to do that to
<nikolapdp>
too
<heat>
obviously ermine just saw this and is moving to GENTOO
<Ermine>
no
<heat>
darn
<Ermine>
no way in hell
<heat>
but you can use openrc :(
<Ermine>
it's a perk for nikolapdp, not for me
<Ermine>
I'm s6 fanboy
<Ermine>
(or perp maybe)
<nikolapdp>
Ermine i don't use openrc
<heat>
skarnet software fanboy vs sysv init fanboy vs systemd fanboy
<heat>
what the heck do you use then
<nikolapdp>
runit
<Ermine>
I'm writing from systemd-powered distro
<heat>
ohhhhhh that's a thing
<nikolapdp>
i am not
<Ermine>
and going to install another one
<nikolapdp>
i am writing from a 2.11 BSD distro
<heat>
Ermine, the best part about systemd is that you literally will never need to think about the init system ever again
<heat>
except when periodically restarting pipewire
<Ermine>
anyway, I want to work on my pc, but my laptop happened to be more powerful
<Ermine>
heat: I've thought about my init system on this weekend, literally
<Ermine>
due to weird interaction of plasma and systemd
<heat>
plasma interacts weirdly with humans too
<nikolapdp>
heat i literally never think about my init system either
<nikolapdp>
what's your point
<Ermine>
yes, that interaction have lead to a weird interaction of me with my computer
<Ermine>
Instead of playing Zuma
<heat>
you thought about it long enough to purposefully switch to a smaller distro with hipster alternatives
<heat>
or you just thought artix is a cool name
<heat>
and fair enough, it is a cool name
<nikolapdp>
you'll never know
<nikolapdp>
what i meant is that i don't think about my init system while using my system
<heat>
Ermine, do alpine packages need to work around not having systemd often?
<Ermine>
I only thought about whether I can be bothered to switch to non-systemd distro
<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
<nikolapdp>
*packages
<Ermine>
heat: does removing /usr/lib/systemd from pkgdir and -Dsystemd=false count? If no, then not
<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
<nikolapdp>
Ermine are you a maintainer of alpine
<Ermine>
that's true
<Ermine>
nikolapdp: yes
<nikolapdp>
i wanted to see what you (alpine) did for new nbd
<Ermine>
nbd?
<nikolapdp>
they changed (broke) their configure to require systemd
<zid`>
nikolar why are you a museum
<nikolapdp>
zid` museum?
<zid`>
yes
zid` is now known as zid
<nikolapdp>
how
<zid>
what do you mean HOW
<zid>
You're running bsd 2.11 on a pdp11
<zid>
the fuck do you think I mean
<nikolapdp>
i am not a museum, i am a human
<zid>
speak serbian technology
<zid>
peak*
<nikolapdp>
lol if only i could find a pdp-11 here
<zid>
get one of your russian clones
<nikolapdp>
they suck
<nikolapdp>
can't run unix
<zid>
but can they run stalinix
<nikolapdp>
also what do you mean my russian clones
<Ermine>
heat: otoh there are rough edges that nobody worked around, mostly due to lack of systemd --user alternative in openrc
<Ermine>
E.g. with dbus-daemon --session and pipewire launching
<bslsk05>
gitea.artixlinux.org: nbd/PKGBUILD at 255f7eac21113b413cf1d6a2508cabdf6b347769 - nbd - Artix Linux Gitea
<nikolapdp>
i just wondered if there was a cleaner way
<heat>
autoconf? run ermine run
<nikolar>
lel
<heat>
oh you're an artix maintainer too?
<heat>
is everyone here a slave to the open source machine?
<nikolapdp>
i think i've mentioned that a couple of times here, but yeah
<nikolapdp>
heat your whole os is open source
<nikolapdp>
are you a slave too
<Ermine>
heat: yes, you can say so
<heat>
yes i'm most definitely a slave to the FOSS machine
<nikolapdp>
then we all are
<Ermine>
(But i'd like to be more involved with Alpine, but my PESSIMALity prevents that)
<heat>
yes
<heat>
sample size of 3 is entirely representative of 260 people
<nikolapdp>
is it not
<heat>
it is
<heat>
ermine is a maths guy he can back me up
<Ermine>
if random enough
<nikolapdp>
see, it's settled
<Ermine>
I'm on academic leave though
<nikolapdp>
doesn't matter, you're still qualified
<heat>
that pkgbase.yaml stuff, is it package CI?
<Ermine>
my qualified mates have already gratuated
<nikolapdp>
heat it is, yea
<heat>
btw what's the relation between arch and artix?
<heat>
package-wise
<heat>
you seem to maintain your own
<nikolapdp>
we do, most our patches are to remove systemd
<nikolapdp>
we sometimes patch things to fix arch's bullshit too
<heat>
so you patch on top of arch?
<nikolapdp>
minimally, but yeah
<Ermine>
so, here's that plasma story
<nikolapdp>
you'd be surprised how often arch's pkgbuilds don't actually build
<Ermine>
So, I have Zuma installed through wine, and I've edited a .desktop file which launches it to use Gamescope
<heat>
the trick is to just use steam and it usually just works
<nikolapdp>
basically
<Ermine>
It's pirated version
<heat>
its 1EUR on steam rn
<nikolapdp>
you can still run it through steam
<Ermine>
Cool, but sanctions
<heat>
cant buy from steam?
<nikolapdp>
can i buy it for you and gift it to yo
<Ermine>
yes
<heat>
yikes
<Ermine>
nikolapdp: no, thank you
<nikolapdp>
lol ok
<heat>
i want to buy euro truck simulator this sale
<nikolapdp>
is the sale still on
<Ermine>
so, anyway, I've launched plasma x11, and gamesope crashed, so game didn't work
<Ermine>
I've removed gamescope invokation from that .desktop file
<heat>
yeah sale's still on
<heat>
no wayland?
<nikolapdp>
no wayland
<Ermine>
but plasma still tried to use gamescope. Even reboots didn't help
<Ermine>
heat: let me finish first
<heat>
yes boss
<Ermine>
so culprit is that plasma created transient service units to launch stuff
<heat>
wow that's cursed
<Ermine>
and the fact I've edited .desktop files didn't affect those services
<Ermine>
So plasma (or systemd) was using older command line which included gamescope
<nikolapdp>
yuck
<Ermine>
And I had to edit app entry using plasma's tool
<Ermine>
so plasma updated the unit
<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
<Ermine>
(or gamescope, but I didn't figure out how to use it yet)
<nikolapdp>
what about the steam version
<Ermine>
Idk
<Ermine>
if steam can get it through gamescope then maybe
<adder>
I believe I'm seeing IRQ8 (clock) but the thing is it shows up only once
<adder>
after that, no more interrupts of any kind
<heat>
can you check if the stacks are "balanced" at entry and exit
<heat>
i don't really recall how the i386 sysv calling convention works
<adder>
do you mean that what gets pushed also gets popped?
<heat>
yes
<adder>
and am I supposed to do it manually?
<heat>
yeah
<adder>
gonna be a while I guess :)
<heat>
as a quick hack you can do something like mov %esp, %eax then compare at exit
<heat>
it'll corrupt your state, but it's already corrupted anyway
theyneversleep has joined #osdev
<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
<heat>
it needs to be $8 cuz you need to clean up the error code too
<heat>
isr number + error code = 8
<adder>
yeah I see
<adder>
I think I need to do more reading to see wtf exactly happens and what gest pushed, otherwise I'm getting nowhere
<adder>
might this stuff be there in the intel/amd manuals?
<heat>
of course
<heat>
but generally your code looks right-ish, if you do add $8
<adder>
hmm, then do we have irq8 followed by a gpf for some reason?
<adder>
ah I know what to do, disassemble ip!
<heat>
yeah do that
<heat>
note: you also want to save/restore segment registers in the future
<heat>
but it's not a problem atm
<adder>
so qemu's going a little too fast, spinning somewhere in a loop
<adder>
not sure how to input the command?
<adder>
iret again
<adder>
needs reading
<heat>
uhhh can the pushal and popal be using the actual instructions instead of the macro?
<adder>
it did not occur to me that there are actual instructions named that way, I'll try renaming
<heat>
would probably not make a difference but, you know, it might be a problem
<adder>
same outcome
<mjg>
pushal, popal and paypal
<mjg>
don't use the last one tho
<adder>
let me read about this, I'll be stuck forever if I don't clear this up for myself
<heat>
it could be that your gdt is busted
<heat>
but i assume you tested that?
<geist>
hmm, this is 32bit x86 right?
<geist>
i guess so, because pusha doesn't exist on 64bit
<bslsk05>
defuse.ca: Online x86 and x64 Intel Instruction Assembler
<chiselfuse>
and vice versa
<zid>
you could write a shell script around nasm/ndisasm pretty easily
<zid>
but yea, I use defuse.ca far too much :(
<geist>
also if it's simple stuff you can try to use gcc.godbolt.org
<geist>
oh i see, locally, yeah
<chiselfuse>
zid: i'll try but i'm not sure i'll get the boilerplate right and all
Left_Turn has joined #osdev
<chiselfuse>
wait isn't defuse.ca open source or something,
Turn_Left has quit [Ping timeout: 268 seconds]
<chiselfuse>
is this a valid instruction: mov r8d,QWORD PTR [rsp+0xb8]
<zid>
Review: noodles aren't as good in the square packs of nong shim ramen compared to the big bowls
<heat>
yes
<heat>
wait, no
<heat>
did something spit that out?
<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
mubluekoor has quit [Quit: mubluekoor]
<geist>
there's no requirement if its implicit
<geist>
the width of the register implies it
<geist>
where the size stuff matters (at least in att syntax) is something like pushing a integer to a memory location
<chiselfuse>
does mov r8d, DWORD PTR ... also zero the top bits of the register?
<heat>
yes
<heat>
it's how every 32-bit partial register works in 64-bit
<heat>
operations on the bottom half zero the upper half
<heat>
like add eax, 0 zeroes the upper half too
<Mondenkind>
so does mov eax, eax
<geist>
and if you do want it to sign extend there's another mov variant
<Mondenkind>
but xchg eax, eax does not
<heat>
xchg does not?
<Mondenkind>
yup
<geist>
welcome to x86
<heat>
yikes. is that a side effect of 0x90 being xchg eax, eax?
<Mondenkind>
hint: nop is encoded as xchg eax, eax
<Mondenkind>
yup
<heat>
fucking lol
<geist>
does xchg only exchange the lower 32 bits? or the entire 64bit reg?
<Mondenkind>
they fixed this at like the last minute in the amd64 spec
<geist>
ah yeah that makes sense, if it does nly the 32bit or the entire register it'd work as a nop
<geist>
TIL some more useless minutae
xenos1984 has quit [Ping timeout: 268 seconds]
<Mondenkind>
looks like it's a special case for xchg eax,eax, so generally xchg r32,r32 would zero the high bits
<heat>
what
<heat>
you're making me really sad now
<chiselfuse>
more info to add to my obsidian x86 notes
<chiselfuse>
how about XCHG r32, r/m32 also only lower dword is exchanged?
<chiselfuse>
zid: do you think i should use ndisasm or objdump for the script?
<zid>
I prefer nasm syntax
<zid>
so I'd do that, personally
<zid>
also less bullshit to cut off the top
<zid>
nidsasm just prints 000000: mov rax, 4
<Mondenkind>
objdump -Mintel
<Mondenkind>
chiselfuse: that exchanges the low dword of the register with the dword in memory, and zeroes the high bits of the register
<zid>
# ndisasm -b64 kernel.bin | head -n1
<zid>
00000000 7F45 jg 0x47
<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
<heat>
Mondenkind, have you heard about our lord and saviour at&t
<heat>
they made UNIX!
<Mondenkind>
wow it just keeps getting better and better
<zid>
chiselfuse: You can make it show you that fine
<heat>
mjg are you team intel or team att
<zid>
it's on the right click menu
<mjg>
what kind of question is that
<mjg>
team at&t
<mjg>
intel syntax looks like roadkill
<heat>
proper UNIX fan
<mjg>
ate by a dog and vomitted back
<Mondenkind>
go back to 1970
<heat>
this is a xenix enjoyer if i've ever seen one
<zid>
can also just do weird stuff like hooking python scripts up to hotkeys
<Mondenkind>
boomer
<heat>
x86 low level code copyright (c) Microsoft Corporation
<mjg>
Mondenkind: i would if i could!
<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?
<mjg>
btw solaris has microsoft-copyrighted code somewhere
<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()
<zid>
also at the top of the function is the stack frame with all the variables, wins -12
<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
<heat>
kof673, that's a BSD gripe
<heat>
beating on BSD is like beating a dead worse
<heat>
horse
<heat>
worse horse really
<kof673>
possibly, but glibc kept "compat"
<kof673>
and posix also ate it up
<kof673>
bsd may have started it :D
<heat>
ofc, what was it supposed to do?
<zid>
yea if it has symbols it will use them, it's an interactive decompiler thingy not a dumb assembly listing
<heat>
they already broke compat on a bunch of symbols and they/we are paying for it
<zid>
if you want one of those that's easily had
<zid>
you can also just split the screen and auto-sync between other views, like the hex view you mentioned
<kof673>
well posix ditched it and there is nanosleep() i guess now :D
<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
<chiselfuse>
i'm making a key binding that takes contents of primary selection and pop ups disassembly using dunst
<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)
<zid>
sounds good
<mjg>
:D
<mjg>
rolling with musl is pulling of a bsd mon
emm has joined #osdev
<heat>
unironically bsd libc is probably pretty high quality
<mjg>
8D
<heat>
i'm sure you can find all sorts of crap in there, don't eight D me
<heat>
BUT it's probably mostly okay
<heat>
*and* can static link
<mjg>
mofo
<mjg>
it's total shite
<mjg>
the original string ops for example were written by someone who heard assembly exists
<heat>
performance is not the main criteria for libc quality
<mjg>
did yo usee that link where said users found out musl string ops were demolishing perf
<mjg>
sad
<mjg>
this was the same shit in freebsd before i sorted it out (mostly, still not OPTIMAL)
<mjg>
it's not a matter of not saving some cycles here and there but actively fucking the perf
<mjg>
the shite memcpy is the same as originally found in freebsd
<heat>
my big problem with musl is not that it's slow, but that the people involved are entirely anti-pragmatism in any way
<mjg>
this is probably big part of why it is slow
vdamewood has joined #osdev
<heat>
yes
<heat>
musl is generally pretty high quality and correct, at the expense of code readability and performance
<heat>
glibc throws you a heavily preprocessed 4000 printf you can barely read as C
<heat>
all in all BSD libc is probably in a decent sweetspot between the two
goliath has quit [Quit: SIGSEGV]
<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
<mjg>
kof673: please update to a newer version
<mjg>
:X
<heat>
mjg, mofer here's a fun question
<heat>
at what point is it worth it to move from O(n) algos to O(log n) or something
<heat>
lets say O(n) is a linked list and O(log n) is a binary tree
<kof673>
i was amazed the installer is basically the same, thought i would have to learn something
<mjg>
heat: i don't think it's fun
<mjg>
heat: by default you want something which does not blow up, so the log n thing
<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
<mjg>
but even then you need to gate the n
<heat>
but the linked list will be empirically faster for small values of n no?
<mjg>
for small values of n you should have an array
<mjg>
and even that sucker can be log n'd
<mjg>
this is basically "should i stab myself in the eye with a fork or a pencil" type of deal
<mjg>
how about you don't
<heat>
it's a perfectly valid question
<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
MrCryo has quit [Remote host closed the connection]
<heat>
because the scale was smaller and the branch predictor was non-existent
<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?
<mjg>
i made a wild assumption you are talking today hardare
<geist>
a really lovely series of freebsds is freebsd4
<geist>
i think it went all the way up to 4.11 too
m3a has quit [Quit: leaving]
m3a has joined #osdev
emm has quit [Quit: WeeChat 4.3.3]
<heat>
geist have you seen the gcc x86 inline asm condition code outputs
<heat>
it's so hot
<geist>
do you mean hot amazing or hot wtf?
<heat>
hot amazing
<heat>
int ccz; __asm__("dec %rax" : "=@ccz"(ccz));
<heat>
basically =@ccCONDITION_CODE
<heat>
it generates optimal sexy asm
<geist>
oh neat. is that new?
<heat>
gcc 6
<geist>
ah good to know
<heat>
iirc they added it for linux, cuz they used to use asm gotos for dec_and_test i believe
meisaka has joined #osdev
gsekulski has quit [Ping timeout: 268 seconds]
<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
* kof673
afk
<mjg>
heat: so for small enough n which you guarantee to be small just use an array
<mjg>
faster than ll's
<heat>
yeah generally that's a good option
<mjg>
and cheaper on memroy
<heat>
C++ people are generally on the std::vector kool aid
<mjg>
what is that internally
<mjg>
ll?
<heat>
no, realloc loop
<mjg>
8s
<mjg>
what's the growth factor on that one
<heat>
2
<mjg>
that's the sensible default
<heat>
insert is amortized to O(1) basically
<heat>
and that does remind me i need a rcu vector implementation
theyneversleep has quit [Remote host closed the connection]
<heat>
however fitting the rcu callback struct will be super messy wrt kmalloc buckets
<mjg>
don't rcu callback it
<heat>
kfree_rcu always needs a struct
<mjg>
you can create a dedicated "this shit frees arrays" routine
<mjg>
then the callback is implicit
<mjg>
you store a number of the arrays in a magic array
<mjg>
and always know how to tear them down
<heat>
arrays all the way down
<heat>
honestly i don't really see what you mean
<heat>
it could be possible to pull off something weird in the slab allocator
<heat>
wins are probably... not that big? it's doubtful that N * sizeof(T) will be a perfect 2^N anyway
<mjg>
you collect them in something
<heat>
well 2^M
<mjg>
the currently rcu-freeable shit is all linked-listed no?
<heat>
yes
<mjg>
instead you create a dedicated array for fuckers
<heat>
yeah but you need to allocate to free, no? if that's what you're getting at
<mjg>
it does run into a problem where the array is of finite capacity tho
<mjg>
allcoate what
<heat>
the array
<heat>
finite doesn't work
<mjg>
you do realize it's all finite
<mjg>
:d
<heat>
you can't just "flush" the array due to it being an RCU free
<mjg>
and i mean pretty tight
<nikolar>
does rcu always make sense (for reader heavy workloads)
<nikolar>
like is rcu-ing the process table fine
<mjg>
heat: no, but if it is has a big enough practical size
<heat>
yes
<mjg>
heat: you could wait for the grace period on overflow
<mjg>
as an emergency measure
<mjg>
nikolar: that's a misleading question
<heat>
hmm that's a decent idea yeah
<nikolapdp>
mjg: got anything to add to that
<mjg>
nikolar: it's always faster to avoid stores to shared areas
<mjg>
which rcu definitely facilitates
<mjg>
but is not the only way to do it
<heat>
SHARDING
<mjg>
another classic is to make the struct copy-on-write
<mjg>
et voila, no fucken' stores and no rcu either
<nikolapdp>
true
<heat>
the linux pid table is fully rcu'd
<heat>
i intend to do that on onyx too
<mjg>
meh
<heat>
the rest *is not* which runs into scalability issuen
<mjg>
this particular aspect is not that great
<nikolapdp>
can you think of any structure that you definitely shouldn't rcu
<mjg>
i can think of cases where rcu usage would be a waste of time
<heat>
write mostly!
<mjg>
but rcu is employed for unrelated reasons
<nikolapdp>
i am talking about correctness mostly, not performance
<mjg>
i don't think that's a valid question
<mjg>
in that case
<heat>
"employing" rcu does not really affect correctness unless your usage is wrong or iffy
<nikolapdp>
well readers could have a slitghtly out of date data, no?
<heat>
rcu read lock is basically an existence guarantee, nothing more
<heat>
nikolapdp, you can use seq counts, flags for that
<mjg>
readers always have out of date data
<mjg>
suppose you have a read-write lock and are racing against a writer
<mjg>
the writer now waits for you to finish
<mjg>
but the writer wants to mess with the state
<nikolapdp>
right, guess so
<mjg>
which it will do immediately after you leave
<mjg>
basically the state is considered stale the cycle you drop the lock
<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;
<heat>
where ref_not_zero is a cmpxchg
<nikolapdp>
interesting
<heat>
basically guarantees you're not getting a stale, dead object
Left_Turn has quit [Read error: Connection reset by peer]
<heat>
rcu is used there as an existence guarantee (this cmpxchg will definitely not fault)
<nikolapdp>
makes sense
<mjg>
for (i = 0; i < n; n++) {
<mjg>
who can spot the bug
<nikolar>
lel
<heat>
i++
<nikolar>
n++
<mjg>
both wrong
<heat>
in C++ that's UB
<mjg>
delete
<nikolapdp>
we don't do c++ here heat
<heat>
actually we do
<nikolapdp>
no, you do
<heat>
wrong
<heat>
the most successful hobby kernels are written in C++
<nikolapdp>
onyx isn't the most successful kernel
<mjg>
openbsd is in c
<heat>
notice the s
<nikolapdp>
mjg what was the bug then
Matt|home has joined #osdev
<mjg>
i am jerking about the fix
<mjg>
the fix is to delte the loop
<mjg>
anyhow i'm off
<mjg>
cheerzen
<nikolapdp>
bye
<heat>
actually i was slightly wrong
<heat>
that loop may or may not be UB in both C and C++
<Mondenkind>
it's ub in c too
<Mondenkind>
or at least something ub-like
<heat>
yeah depends if n is signed
<nikolapdp>
are you referring to the overflow behaviour
<heat>
yes
<nikolapdp>
is the loop ub then, or just the increment
<heat>
if n is signed, it's UB on both. if n is unsigned, it's UB in C++ only
<Mondenkind>
oh no i wasn't talking about that
<Mondenkind>
it's infinite loop ub
<Mondenkind>
:)
<nikolapdp>
because if it's just the increment that it will emit inc %rax and you'll be fine
<nikolapdp>
in c
<Matt|home>
o\
<heat>
it's still UB
<heat>
oh i had a great quote for this moment
<Mondenkind>
wait hmm. if it's unsigned then it's infinite loop ub. if signed then overflow ub
<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?
<heat>
<heat> kiss the girls you didn't ask while arguing UB on IRC
<heat>
<heat> didn't kiss*
<Matt|home>
for modern OS
<nikolapdp>
Matt|home: bad
<geist>
good
<Matt|home>
luls
<Mondenkind>
i agree with both answers
<nikolapdp>
lel
<heat>
ignore the C++ hater
<nikolapdp>
ignore heat
<heat>
it's good if you like C++, it's bad if you don't
<Mondenkind>
ignore both of them
<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
<Matt|home>
did not wanna start a debate :D i was just curious on a whim
<heat>
there's really no debate, it's perfectly adequate if you like the language
<nikolapdp>
zid that's what i was referring to
<zid>
exec("nethack") time
<Matt|home>
copy that
<heat>
it's still perfectly adequate if you don't like it, but then you just don't use it
<Mondenkind>
'is x good or bad' is not a useful question in general
<nikolapdp>
indeed
<Mondenkind>
(that said uhhhh c++ is definitely bad)
<nikolapdp>
there we go
<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
<heat>
and tradition
<Matt|home>
so idk how much overhead using C++ would bring in terms of performance
<heat>
tradition more than any other reason
<heat>
like these kernels are ooooooooooooooooold
<geist>
well, it's not a great question, but if you get smoething universally non polarizing that's a good direction
<geist>
like 'kernel in COBOL? Y/N'
<geist>
i doubt a lot of folks would seriously say Y
<heat>
obviously yes
<kof673>
surely KERNEL IN COBOL? Y/N
<kof673>
(i do not know, but i would bet on it)
<Matt|home>
lemme rephrase the question then to be more technically accurate
<nikolapdp>
was there a kernel in cobol?
<nikolapdp>
maybe something from ibm lol
<kof673>
it was a capitalization joke :/
<kof673>
yes, probably :D
<nikolapdp>
kek
<geist>
fortran maybe. lots of systems stuff was written in various dialects of fortran
<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
<Matt|home>
or not even by milliseconds in terms of real world usage
<geist>
but really early kernels up through the 70s were almost certainly written in asm or some macro assembler like language
<heat>
Matt|home, it depends
<nikolapdp>
well if you use inheritance, then c++ is going to be slower
<heat>
C and C++ will be very similar
<geist>
Matt|home: not really. no. but then what you do with the language matters
<nikolapdp>
due to virtual dispatch etc
<heat>
nikolapdp, what?
<Matt|home>
okay so im getting a lot of "it really depends". understood
<nikolapdp>
yes, it really depends
<heat>
if you're using virtual dispatch in C++ you'd use a function pointer in C
<heat>
it's really the same thing
<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
<geist>
and when the code base gets large enough that sort of stuff tends to matter more
<Matt|home>
i guess im operating under the incorrection assumption that some languages are more efficient than others
<geist>
it's hard to imagine writing any large codebase in C nowadays. and then you can debate what 'large' is
<heat>
that's not entirely incorrect
<heat>
like C vs java is a pretty easy dilemma
<geist>
right, but... C++ is not really any more inefficient per se than C
<geist>
it just lets you build more abstract concepts that may not be as straight line optimized as you can hand write in C
<kof673>
i would bet if no cobol kernel, probably some app that was the main thing running :D
<nikolapdp>
oh that definitely
<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
<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
<Matt|home>
"C
<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."
<Mondenkind>
go not really lol
<heat>
it has been done
<Matt|home>
mkay
<Mondenkind>
java perf wise i would expect to walk all over go
<geist>
keep in mind most modern production kernels were started in the 80s or 90s. and at the time the equation was definitely different
<geist>
C was the defacto language
<heat>
see the mit pdos go unix kernel
<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
<Matt|home>
so it's still well within the realm of reasonableness to write a full modern kernel in C
<nikolapdp>
absolutely
<heat>
uhhh define reasonableness
<Mondenkind>
and java vs c probably O(10-20%) at worst, and mostly because of the way the language encourages you to write code
<geist>
sure, mine have always been in C as well, but they're older and smaller
<Matt|home>
i mean i just read from the wikipedia page, the NT kernel is pretty much written in straight C
<heat>
that is wrong
<Matt|home>
and that's a big kernel
<nikolapdp>
was
<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
<bslsk05>
learn.microsoft.com: One Dev Question with Raymond Chen - What Programming Language is Windows Written In? | Microsoft Learn
<heat>
mjg, where is what
<Matt|home>
"most of the kernel code is still in C"
<mjg>
rust which you can't use
<zid>
yea technically C++ can be used to great effect, it's all the non-technical things I find fault with mainly
<zid>
safe subsets, etc
<nikolapdp>
(which is c :P)
<heat>
it's not rust which you can't use, it's people that can't use rust (because they don't know it)
<zid>
I prefer the language to just be 'it's this, do this'
<geist>
indeed. you need to be careful about defining it
<zid>
save people from themselves
<Matt|home>
main reason they're citing keepiung it in C is apparently because of C++'s auto generation
<nikolapdp>
auto generation?
<zid>
how many null pointers is C++ up to now? :P
<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
<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
<geist>
but in general its okay, and very powerful
<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"
<Matt|home>
that's their cited reasons
<zid>
Maybe if we really were in a "linux is C++" universe
<heat>
bullshit
<zid>
the push hook linters would be super great
<zid>
and tell you off for doing a bunch of things
<geist>
NT does have pagable kernel memory, which i'm sure they regret now. that might cause problems there
<mjg>
heat: well i am advocating for rust over c or c++ for a new proj
<geist>
also there's the whole loadable driver model, which causes C++ ABI issues
<mjg>
pageable memory is something they can stop doing
<mjg>
i mean what is going to break if they drop it
<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
<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
<heat>
or you fit into one of my 3 points
<mjg>
anyhow now i'm really off, cheers
<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
<geist>
add some RAII bits here and there (that's hecka convenient). or some simple structs with helper methods on it, etc
<heat>
there are bazillions of NT code in C++ mainly because AFAIK it's the main language used for driver development there
<nikolapdp>
when heat does that he calls it c
<geist>
nothing in C++ requires that you go Full Java and put everything in a class or whatnot
<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
<geist>
so you have to be a bit careful
<heat>
subscribe
<heat>
that's my brand of c++
<heat>
but really when microsoft did dtrace for windows they had to add some small tidbits of C++ support
<nikolapdp>
geist: re david plumber
<geist>
right
<heat>
it is entirely likely some non-trivial bits are written in C++
<geist>
yah, totally possible you can use C++ in kernel drivers but the driver API is almost certainly C
<geist>
but that's also totally doable
<heat>
yep
<geist>
thats where yo uget into the 'what is the kernel' thing when talking about modular kernels like NT
<geist>
most likely it's not in one codebase at all, lots of separate repos within msft, etc
<heat>
C API/ABI with C++ code internally is an entirely sensible approach that even userspace projects do
<geist>
yah that's what i'm generally doing with LK nowadays. writing new things in C++ but keeping the C api between modules
<nikolapdp>
didn't ms make a lot of git contributions because they are basically working in a massive monorepo for windows
<heat>
i don't think windows uses git
<geist>
they definitely had their own thing for a while, from what i heard, but i think they switched relatively recently to something new
<nikolapdp>
there was a presentation by one of the important guys at github that mentioned that factoid
<nikolapdp>
i think
<geist>
but a monorepo doesn't mean you have everything under one directory
<heat>
geist, i've been scaling back the little C++-yness i had and even writing full functionality in C
<heat>
mostly because i'd like to use the infra around current kernels, and also to prepare eventual rust experiments
<geist>
word; what i've generally found is drivers are really lovely C++ places
<geist>
they're basically leaf nodes, basically object oriented anyway, since it's a drier working on an instance of a device
<heat>
yeah totally
<heat>
like who cares there, just don't have a struct class and we're all fine
<geist>
things that are large singletons dont really match the C++ object layer as much
<heat>
my big problem is that lots of great stuff doesn't grok C++, dtrace doesn't, bpftrace doesn't
<geist>
yah, super long ass symbols really annoying for tracing
<heat>
which if you'd like to integrate those great tools, it screws you up
<heat>
oh struct randomization doesn't too!
<nikolapdp>
struct randomization?
<heat>
yes
<geist>
forced structure layout, mostly due to inheritance, in C++ is one of the worst parts that you can't easily work aroun
<heat>
it's a gcc plugin/clang feature that randomizes member placement around the struct
<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
<nikolapdp>
heat: for debugging purposes i imagine?
<geist>
ad if yo uhave a big singleton object (TheScheduler, etc) you can't do things like force variables into particular sections, etc
<kof673>
"security" young nikola
<nikolapdp>
struct randomization, really?
<heat>
security
<kof673>
someone mentioned it here a few months ago is only reason i recall
<heat>
it's entirely sensible
<nikolapdp>
interesting
<heat>
if the attacker doesn't know the seed, its exploitation methods are limited
<nikolapdp>
how often does exploit rely on struct member ordering though
<geist>
lots
<zid>
You'd be surprised
<geist>
any buffer overrun style thing is mostly about trying to tweak something in a neighboring data structure
<zid>
C++ is actually super exploitable compared to C because of all the function pointers floating around in data structures
<geist>
indeed, you can i guess replace the vtable and point it at your own thing
<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
<zid>
n^x, relro, etc
<zid>
all protect C but do very little to protect the main attack on C++
<zid>
You need the CET crap from windows to stop it
<nikolapdp>
what's CET
<zid>
function pointer authentication, basically
<zid>
you have to have a special opcode embedded anywhere a call instruction could land else it blows up on you
<zid>
to stop you doing things like jumping over the `if` in if(admin) do_special_thing();
<zid>
with a corrupted function pointer
<nikolapdp>
oh right, those are the weird instructions at the start of functions
<nikolapdp>
i remember
<zid>
there's also some bitmap shit
pog has joined #osdev
<zid>
that makes it CET and not just intel whatever
<zid>
shadow stacks
<nikolapdp>
i forget, are there hardware shadow stacks on x86
<zid>
CET is controlflow enforcement technology
<zid>
yes but they suck, afaik
<zid>
so CET is mostly software stuff
<nikolapdp>
interesting
<geist>
yah we use shadow stacks on x86 in fuchsia, and its not terribly cheap
gog has quit [Read error: Connection reset by peer]
<geist>
for ARM we use shadow call stacks, which is somewhat more efficient, but not really feasible on x86
<nikolapdp>
geist, software shadow stacks i assume, on x86
<geist>
yeah
<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
<nikolapdp>
ah yuck
<zid>
or against a big bitmap of valid landing targets
<nikolapdp>
geist, arm has hardware shadow stacks too
<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
<heat>
adder, haha found your bug
<adder>
no shit? :)
<zid>
I think that big bitmap code fucking exploded in one of those windows internals blogs
<heat>
you have interrupts on without remapping the PIC
<geist>
so the compiler figures out where data goes
<heat>
you're getting an IRQ at vector 8 (exception with error code)
<zid>
'800 cores and chrome is slow' or 'compiling chrome takes 47 days on windows' one of those blog posts
<heat>
therefore stack gets fucked
<nikolapdp>
lel
<heat>
e=0204 looks like iret is trying to load your eflags as a segment register