Gooberpatrol_66 has quit [Quit: Konversation terminated!]
Gooberpatrol_66 has joined #osdev
chiselfuse has quit [Ping timeout: 260 seconds]
chiselfuse has joined #osdev
craigo has joined #osdev
X-Scale has joined #osdev
goliath has quit [Quit: SIGSEGV]
heat has quit [Ping timeout: 252 seconds]
_ngn has joined #osdev
gog has quit [Ping timeout: 246 seconds]
<immibis>
is that well known knowledge among people who actually write kernels or is there some specific rationale? seems like you could lock (that part of) the process's address space, prepare a page table equivalent to the (let's assume) 2MB huge page you're replacing, update the page directory, then flush TLB on all processors i.e. (I presume) "make before break". But that seems obvious and I don't write kernels so I assume there are very good reasons why the
<immibis>
obvious thing is actually impossible.
leon has joined #osdev
<geist>
it's an arcitectural specific detail. some arches are okay with doing what you ask, some are not
<geist>
ARM in particular is very picky about BBM to avoid having multiple TLB entries present at the time that cover the same page. to have that situation is a special type of exception that is generally bad
Arthuria has joined #osdev
X-Scale has quit [Quit: Client closed]
X-Scale has joined #osdev
alexander has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
Matt|home has joined #osdev
Matt|home has quit [Read error: Connection reset by peer]
alexander has joined #osdev
Matt|home has joined #osdev
qubasa__ has quit [Ping timeout: 246 seconds]
_ngn has quit [Quit: WeeChat 4.4.1]
edr has quit [Quit: Leaving]
levitating has quit [Ping timeout: 276 seconds]
levitating has joined #osdev
JupiterBig has joined #osdev
Arthuria has quit [Ping timeout: 276 seconds]
<immibis>
why would it fill the TLB if it finds the virtual address already present in the TLB?
JupiterBig has quit [Ping timeout: 248 seconds]
the_oz_ has joined #osdev
JupiterBig has joined #osdev
<zid`>
maybe it also applies to different virtual addresses?
JupiterB1g has joined #osdev
vdamewood has joined #osdev
JupiterBig has quit [Quit: leaving]
JupiterB1g has quit [Quit: leaving]
levitating has quit [Read error: Connection reset by peer]
levitating has joined #osdev
Mondenkind has quit [Quit: !]
childlikempress has joined #osdev
SGautam has joined #osdev
levitating has quit [Ping timeout: 272 seconds]
foudfou has quit [Quit: Bye]
foudfou has joined #osdev
bliminse has quit [Quit: leaving]
Gooberpatrol66 has joined #osdev
Gooberpatrol_66 has quit [Ping timeout: 276 seconds]
steelswords has quit [Read error: Connection reset by peer]
steelswords has joined #osdev
j00ru has quit [Ping timeout: 260 seconds]
the_oz_ has quit [Quit: Leaving]
mrkajetanp has joined #osdev
mrkajetanp has quit [Ping timeout: 252 seconds]
antranigv_ has joined #osdev
antranigv has quit [Ping timeout: 245 seconds]
bliminse has joined #osdev
_ngn has joined #osdev
<_ngn>
in #ircchads
_ngn has left #osdev [#osdev]
_ngn has joined #osdev
bliminse has quit [Client Quit]
bliminse has joined #osdev
bliminse has quit [Client Quit]
bliminse has joined #osdev
bliminse has quit [Client Quit]
bliminse has joined #osdev
antranigv_ is now known as antranigv
goliath has joined #osdev
GeDaMo has joined #osdev
xvmt has quit [Remote host closed the connection]
xvmt has joined #osdev
* klys
is open to creating accounts at https://words.showing.beauty/s/wiki/ for any devs in this group. wanted an irc-mediated wiki/quote/lists experience, settling for a wiki for now. may add gitweb to my server in the future. specs: 56 threads, 256GB ram, 2TB swap, ~12tb SAS HDD storage and ~800GB/2TB free on ssd.
SGautam has quit [Quit: Connection closed for inactivity]
<heat>
immibis, well for one TLBs are frequently separated by page size
<heat>
it's not hard to imagine how you would have two entries for the same range on separate "sub TLBs" (say, 2M and 4K)
<immibis>
if 2M lookup succeeds why would it go and load a new 4k entry from memory?
<heat>
there are a bunch of funny edge cases
<heat>
like "L1 dTLB miss, now you're looking into the L2 TLB, oh you found a 2M TLB entry (which was never invalidated)"
<heat>
L2 being shared
vai has joined #osdev
vai is now known as Jari--
craigo has quit [Quit: Leaving]
tru3humandesign has joined #osdev
mrkajetanp has quit [Ping timeout: 248 seconds]
xenos1984 has quit [Read error: Connection reset by peer]
mrkajetanp has joined #osdev
xenos1984 has joined #osdev
levitating has joined #osdev
mrkajetanp has quit [Ping timeout: 246 seconds]
mrkajetanp has joined #osdev
edr has joined #osdev
levitating has quit [Ping timeout: 248 seconds]
levitating has joined #osdev
tru3humandesign has quit [Quit: WeeChat 4.4.1]
strategictravele has joined #osdev
strategictravele has quit [Max SendQ exceeded]
levitating has quit [Remote host closed the connection]
levitating has joined #osdev
strategictravele has joined #osdev
levitating has quit [Ping timeout: 246 seconds]
strategictravele has quit [Read error: Connection reset by peer]
levitating has joined #osdev
linear_cannon has quit [Read error: Connection reset by peer]
strategictravele has joined #osdev
levitating has quit [Remote host closed the connection]
levitating has joined #osdev
strategictravele has quit [Client Quit]
hwpplayer1 has joined #osdev
levitating has quit [Ping timeout: 244 seconds]
levitating has joined #osdev
levitating has quit [Ping timeout: 264 seconds]
freakazoid332 has quit [Read error: Connection reset by peer]
Left_Turn has joined #osdev
jedesa has quit [Remote host closed the connection]
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 245 seconds]
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
frkazoid333 has joined #osdev
stolen has joined #osdev
andydude has joined #osdev
vdamewood has quit [Quit: Life beckons]
jedesa has joined #osdev
netbsduser has quit [Ping timeout: 252 seconds]
netbsduser has joined #osdev
mrkajetanp has quit [Ping timeout: 252 seconds]
theyneversleep has quit [Remote host closed the connection]
andydude has quit [Quit: Leaving.]
spareproject has joined #osdev
heat has quit [Ping timeout: 248 seconds]
Arthuria has joined #osdev
Matt|home has quit [Read error: Connection reset by peer]
fish_head has joined #osdev
netbsduser has quit [Ping timeout: 255 seconds]
mavhq has quit [Ping timeout: 265 seconds]
mavhq has joined #osdev
<geist>
yah as heat is saying there are tons of edge cases. the ARM ARM talks about a bunch of them and lays it out pretty explicitly
<geist>
i forget if on any of the x86 machines there's a need for BBM
jedesa has quit [Remote host closed the connection]
<geist>
a lot if it is x86 has a bunch of extra hardware to deal with these edge cases because Backwards Compatibility
<geist>
but newer designs (ARM, riscv, etc) make it a software problem so they can just remove the hardware
jedesa has joined #osdev
<geist>
for example it may very well be that x86 hardware detects a multiple TLB entry collision like this and stops, runs some microcode to clear all the affected entries and restart the TLB miss
<geist>
and ARM/riscv/etc just doesn't want to add that extra hardware if it doesn't need to. they throw an exception and make it a software problem
<geist>
and this is not isolated, thats a general philosophy of most risc designs
_ngn has quit [Ping timeout: 260 seconds]
mrkajetanp has joined #osdev
mavhq has quit [Ping timeout: 264 seconds]
steelswords has quit [Ping timeout: 255 seconds]
stolen has quit [Quit: Connection closed for inactivity]
mavhq has joined #osdev
mavhq has quit [Read error: Connection reset by peer]
Jari-- has quit [Ping timeout: 272 seconds]
_whitelogger has quit [Ping timeout: 252 seconds]
_whitelogger has joined #osdev
steelswords has joined #osdev
<kof673>
doesn't apply here surely, but...mechanism not policy. "here is a mechanism, up to the user/programmer to use it or not"
<kof673>
i mean i would put as similar maybe
frkazoid333 has quit [Read error: Connection reset by peer]
<kof673>
manual versus anything "automatic"
<kof673>
or...similar thing at software levels...
frkazoid333 has joined #osdev
truebad0ur has joined #osdev
plasma41 has joined #osdev
Turn_Left has quit [Ping timeout: 245 seconds]
op has joined #osdev
spareproject has quit [Ping timeout: 272 seconds]
frkazoid333 has quit [Read error: Connection reset by peer]
<mjg>
fucking linkedin
<mjg>
i made the mistake of reading my feed
<mjg>
got a "recommended post" from some webdev twat explaining why node.js is FAST
<mjg>
LOL
<mjg>
precisley the kind of a fuck which needs to get fired and not find a job in IT afterwards
<mjg>
fuck
<rbox>
lol
<rbox>
"fast" compared to what
<mjg>
fuck if i know
<rbox>
lol
<geist>
to something slower
<mjg>
node.js deployed on solaris deployed on sparc is where perf is at
dude12312414 has quit [Remote host closed the connection]
<geist>
sounds like someone has a case of the fridays
gog has joined #osdev
<sortie>
:D
<sortie>
geist: Hehe mostly that I updated my OS to gcc 14.2.0 (midway) so I commited a ton of fixes for bugs, warnings, port issues, etc. and then waited a week to make sure everything was tested in every way, finally passed all the tests, so merged :)
<sortie>
It gets a bit tricky because my OS also has to work with gcc 5.2.0 still for bootstrap reasons, so did some testing to make sure the old toolchain still worked, and it didn't. Mostly cus I accidentally used some gcc 14 features and warnings that made the old gcc warn or error
<geist>
ah yeah
<sortie>
This is the part of osdev that I kinda enjoy, putting it all together. Making my OS work in every mode, for now, temporarily, with quality where possible, hacks where needed, plus workarounds, with a full bootstrap plan. So my old 1.0 release with gcc 5.2.0 and binutils 2.24 is able to bootstap the new version with gcc 14.2.0 and binutils 2.43.1.
<sortie>
Lots of testing needed for that. All carefully planned ahead of time, heck even back in 2016 with forward compat. So I can say it's fully supported to upgrade from source.
<geist>
yeah that's always nice
<geist>
also yay i have a new keyboard out for delivery
<geist>
Drunk Deer G75
<sortie>
And it's tricky. We literally found a bug in gcc and made a minimal reproduction and managed to even find an existing issue for it
<sortie>
Yay keyboards
<sortie>
That's what me and my musician friends have in common. I'm pretty awesome on a keyboard. The QWERTY kind lol
<geist>
typed on one when i was at akihabra in japan, and it immediately stuck out to me
<sortie>
Ooh I heard of akihabra that's cool
<geist>
yah it was literally in the Steins;Gate building too
<sortie>
I got mildly concerned when gcc started warning me about iteration 2147483648
<Xyon>
bestie wrote the os that turns us all trans in the end, for sure
antranigv is now known as antranigv_
<the_oz>
maybe it's something deeper one learns about the nature of playing a role of an attractive female, with which it comes with stretching the muscles of body hacking
<heat>
i do have to say it's very sad how the kernel world has so few women
<heat>
even compared to the rest of compsci
<the_oz>
practice makes perfect and all that
<heat>
it seems that kernel hacking isn't brat enough
Gooberpatrol66 has quit [Quit: Konversation terminated!]
Gooberpatrol66 has joined #osdev
antranigv_ is now known as antranigv
<the_oz>
make kernel hackjing easier? I mean...
<the_oz>
failing for that you won't believably delude it
steelswords has quit [Read error: Connection reset by peer]
<sortie>
Today in osdev: I figured out why the new binutils on my OS made a program that crashed when the old ld worked.
<sortie>
It's a difference in the built-in linker script related to the semantics of the init_array section for constructors where it does something new that my libc does not support
<sortie>
Protip: You can use -Wl,--verbose to gcc to make it forward --verbose to ld that makes it spit out its linker script
Gooberpatrol66 has quit [Ping timeout: 276 seconds]
<sortie>
The solution for me was to set ENABLE_INITFINI_ARRAY=no in my ld emulparams for sortix
<sortie>
Curiously, this only happened with a natively built binutils 2.43.1 because the feature is not enabled when binutils itself is cross-compiled
<sortie>
It's also not enabled for crosscompiler
<heat>
fix your libc?
<heat>
instead of hacking around it
<sortie>
heat: Arguably the old way is my ABI
<sortie>
But honestly I just don't understand the way to do constructors here
<heat>
what's the difference?
<sortie>
There's a bit of variance in how the crt stuff is done across platforms and I'm a bit confused and need to research
<heat>
IIRC most new platforms don't support old style ctors at all, just init_array
dgz has quit [Ping timeout: 272 seconds]
<heat>
clang IIRC does not support old style at all either
<sortie>
I don't think I support init_array
mrkajetanp has quit [Ping timeout: 276 seconds]
<sortie>
I do some stuff but it's been ages since I looked into it
<sortie>
Nonetheless whatever I happened to do in 1.0 is the ABI for now (since I cannot break the ABI in 1.1 -- due to 1.0 -> 1.1 bootstrap reasons, I will be able to change the ABI for 1.2) unless I learn more and plan out a way to transition
<sortie>
I'll need to learn a lot more tho
<sortie>
A bit pressing question is e.g. why init_array exists at all and what was wrong with the old approach
<heat>
it requires crtinit junk
<heat>
the current way to do ctors:
<heat>
call _init; call every member of init_array
<heat>
you call _init if anything isn't using init_array ctors ofc
<heat>
which you can't know ahead of time
<sortie>
I mean that's massively simplified. There's all sorts of section stuff going on, plus linker script fun plus sorting, cooperation with crti and crtn and crtbegin and crtend and what not and I need to swap in all of those details :)
<heat>
it's not massively simplified. this is how it works
<heat>
linker sorts everything into init_array. you call every member (function pointer) of init_array. you're done
<heat>
it's not hard
<heat>
crti and crtn do not exist in many new platforms, crtbegin and crtend do not exist on e.g clang
<bslsk05>
maskray.me: .init, .ctors, and .init_array | MaskRay
<sortie>
I mean I hear you and it helps but I also need to study the authoritative information, understand the migration path, the implementation concerns, compatibility and bootstrap issues, etc.
fedaykin has joined #osdev
<sortie>
Thanks for the link :)
<sortie>
Just saying this isn't a 2 AM thing :) For now my concern is just making the new binutils work
<heat>
like this is generally transparent to the toolchain apart from calling things properly in the libc, and your linker script if you need to mes with that
<heat>
right
<sortie>
I knew I needed to deal with this area one day anyway