<pog>
are you trying to build freestanding libstdc++? i managed to do it once but i can't recall how
<pog>
it was years ago
zhiayang has joined #osdev
zhiayang has quit [Client Quit]
bauen1 has quit [Ping timeout: 245 seconds]
zhiayang has joined #osdev
phoooo has quit [Quit: Client closed]
Valeria22 has joined #osdev
phoooo has joined #osdev
eddof13 has joined #osdev
heat has joined #osdev
<heat>
pog
<pog>
heat
* phoooo
wants hug
* heat
hug
* heat
pog heat pog heat pog heat pog heat pog
<pog>
pogpogpog
* pog
hug phoooo
<heat>
warmthwarmthwarmth
gog has joined #osdev
gog has quit [Client Quit]
<sham1>
POGGERS
<heat>
we had pog and gog?
<heat>
this is a gogspiracy
<pog>
yes
eddof13 has quit [Ping timeout: 246 seconds]
<zid>
we're having a gogsplosion!?
Burgundy has joined #osdev
<pog>
a gogtastrophe
vdamewood has joined #osdev
stolen has quit [Quit: Connection closed for inactivity]
netbsduser` has quit [Ping timeout: 250 seconds]
<zid>
gog ass trophy!?
<pog>
that it is
* pog
twerk
<heat>
i leave for 10 minutes and you start twerking smh
<heat>
screw this im going to play pretend football manager again
joe9 has joined #osdev
SGautam has quit [Quit: Connection closed for inactivity]
phoooo has quit [Quit: Client closed]
yoyofreeman has quit [Remote host closed the connection]
yoyofreeman has joined #osdev
yoyofreeman has quit [Remote host closed the connection]
yoyofreeman has joined #osdev
netbsduser` has joined #osdev
<pog>
i'm gonna play factorio when i get home
xenos1984 has quit [Read error: Connection reset by peer]
yoyofreeman has quit [Remote host closed the connection]
yoyofreeman has joined #osdev
<sham1>
Starts twerking exactly when heat is away. How rude
<pog>
i'll wait until he can observe next time
heat has quit [Remote host closed the connection]
xenos1984 has joined #osdev
heat has joined #osdev
pog has quit [Quit: Konversation terminated!]
stolen has joined #osdev
Vercas1 has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas1 is now known as Vercas
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
<geist>
heat: thanks for reminding me re: the #riscv channel, i still need to add cross cpu IPIs for fence.i
<geist>
also a thing i think qemu doesn't really emulate and thus works great
<Ermine>
found on internet: current_sec = int(datetime.now().strftime("%S"))
gog has joined #osdev
FreeFull has joined #osdev
<kof123>
(maybe outdated) linux vdso(7): Why does the vDSO exist at all? There are some system calls the kernel provides that user- space code ends up using frequently, to the point that such calls can dominate overall perfor‐mance. This is due both to the frequency of the call as well as the context-switch overhead that results from exiting user space and entering the kernel.
<kof123>
this was not a comment on anything except "there are layers" > Thus the kernel arranges for the information required to answer this question to be placed in memory the process can access. Now a call to gettimeofday(2) changes from a system call to a normal function call and a few memory accesses.
SGautam has joined #osdev
<sham1>
Hmm, at least glibc doesn't at least seem to use the vdso
<sham1>
In fact, neither does musl. Both use clock_gettime
<sham1>
Well, glibc uses __clock_gettime
<sham1>
Although I'd suppose that clock_gettime also does a vDSO thing
<Ermine>
vdso is shipped by the kernel
<geist>
depends on the arch. i think the real original intent was to encapsulate the syscall mechanism on x86-32
<acidx>
clock_gettime() it's also through vDSO on Linux (x86-64 at least)
<geist>
since x86-64 has a single syscall instructino, there's less of a need for it for *all* syscalls
<Ermine>
Afaik this is a trick to speed up stuff
<gog>
it can be used in place of syscalls that don't really need to be syscalls
<gog>
there's also io_uring now that supplants some syscalls i think?
<sham1>
What I don't get is how the vDSO gets access to the relevant kernel data if it's mapped into usermode
<sham1>
Is the relevant data also mapped to user mode?
<acidx>
Yes
<sham1>
Oh eww
<sham1>
I mean, it makes sense but still
<heat>
sham1 both musl and glibc use vdso
<acidx>
vDSO is a bit of a hack (relying on symbol interposition and whatnot), but it's kinda clever as it also provides forward-compatibility without breaking the ABI
<heat>
you won't see clock_gettime in strace
<sham1>
Yes, but neither uses the gettimeofday vDSO from what I can tell, but both instead use clock_gettime which in turn does vDSO
<geist>
right, we take the vdso to the next leve in zircon by forcing *all* syscalls through it
<geist>
ie, it's not legal to put a syscall instruction in your binary, you must link with the vdso and then it has a stub per syscall
<geist>
most of the stubs are 'move args to regs, syscall instruction'
<geist>
but it handles the ABI expansion nicely, new syscalls can be added, some syscalls can be locally implemented, old syscalls can be refactored in terms of new syscalls, etc
<gog>
neat
<gog>
i like that
<geist>
and we can have multiple vdsos with some syscalls nulled out
<gog>
i like anything that makes deleting code easy
<sham1>
Deleting code++
<geist>
the only real downside is user spac e*must* link with it, and there's a slight overhead to having to make a function call
<geist>
iirc mac does something kinda similar
<sham1>
OpenBSD also does that
<sham1>
If you call a syscall, OBSD *kills* your process unless the syscall came from the libc
<geist>
yep,, same with zircon
<geist>
there's an easy table in the kernel that says 'if the syscall instruction isn't at this offset from the base of the vdso, it's invalid'
<acidx>
if you did what vDSO does differently (e.g. for time APIs), let's say with a syscall that maps in a shared page, it would suck if you needed to change the struct there in the future. for instance, to support different clock sources, precisions, or whatever might be important in the future. with symbol interposition, that's 100% transparent.
<geist>
yah the vdso can implement it in whatever way it wants, and the implementation is provided by the kernel so it can stay in lock step with however the data is published into its data section
<geist>
since the kernel patches it
<acidx>
geist: I like it being in the vDSO rather than the libc like OpenBSD does. makes it easier for non-C languages to be ported to the system
<geist>
yah. only downside ther eis you need to pick a binary format, or have multiple vdsos for different formats
<geist>
ELF vs PE, for example
<gog>
ELF ELF ELF
<sham1>
Well an OS would probably have to pick one anyway
<geist>
EEEEEELLLLLLFFFFF
<gog>
RUUUUST
<sham1>
NOOOOO
<geist>
well, for example, Go is a weird one since it doesn't do libs, etc
<geist>
so its loader has to deal with it manually
<geist>
but so it goes.
<heat>
haha syscall go brrr
<sham1>
syscall? You mean a function call
<acidx>
do we have an ORC format? (Object with Relocatable Code)
<sham1>
haha, lisp machine OS go Brrrrr
<heat>
vdsos being required is lame
<heat>
static linking where??
<gog>
static linking baed
<sham1>
ew, static linkage
<heat>
PLT/GOT overhead? dont even need to ask where
<geist>
yeah but you static link everything up to the vdso
<sham1>
Couldn't you get rid of PLT/GOT stuff with rip-relative addressing? Probably not. Sad
<gog>
PLT PLT GOTPLT
<gog>
GOGPLT
<heat>
usually if you don't royally fuck things up your first time (cough cough fucking linux) you don't need to refactor syscalls all that much anyway
<gog>
implementing posix is a mistake
<heat>
sham1: no, since they're not in the same DSO
<sham1>
Stop implementing POSIX in userspace
<sham1>
Err, kernelspace
<sham1>
POSIX in userspace!
<heat>
yes, implement posix in userspac
<heat>
make it slow
<sham1>
NANOKERNEL NANOKERNEL NANOKERNEL
<heat>
VIMKERNEL VIMKERNEL VIMKERNEL
<gog>
implement nothing
<gog>
EXOKERNEL
<sham1>
heat: don't you have a football team to manage?
<heat>
i drew cuz my team didnt score in an important game, quit and now im playing csgo with a friend
<heat>
seriously how does one get an xG of 1.5 and not score a fucking goal
<heat>
im always drawing in UCL games and then I come back to the league and 5-0 someone
<Ermine>
So, given that there are vdsos, static linking is a dream?
<geist>
well, it just depends on if you mean 100% absolute static linking
<geist>
or defacto static linking
<geist>
ie, static linking for things that you provide, which is the gist of it
<gog>
never link
<geist>
technically you never get static linking anyway, if you think of the kernel as a component that you dont link into your app
<heat>
libkernel
<heat>
!!
<Ermine>
I don't really call kernel, I use interrupts to syscall
<geist>
think of the vdso as just a little piece of thekernel that exists in user space
<sham1>
LTO all the way to thekernel boundary
<gog>
take another little piece of my kernel now baby
<gog>
i'm learning how to production logic in factorio
<gog>
this is actually pretty powerful
<gog>
my favorite is how you can feed back a value into a comparator and get a latch or an accumulator
<bslsk05>
lore.kernel.org: [PATCH] x86/CPU/AMD: Fix the DIV(0) initial fix attempt
<heat>
holy shittt wtf is this bug
<heat>
Under certain circumstances, an integer division by 0 which faults, can
<heat>
leave stale quotient data from a previous division operation on Zen1
<heat>
microarchitectures.
<heat>
Do a dummy division 0/1 before returning from the #DE exception handler
<heat>
in order to avoid any leaks of potentially sensitive data.
<Cindy>
heat: crappy intel design
<Cindy>
not linux's fault
<heat>
this is fucking AMD
<Cindy>
crappy AMD* design
<heat>
also when did I ever blame linux
<heat>
i'm shitting on *AMD*
<Cindy>
oh whatever, intel and AMD are doing crappy hacks on x86 at this point
<Ermine>
Was that highlighted on phoronix?
<heat>
there's a crappy article on phoronix
<heat>
i haven't seen an exploit for this one
<heat>
just commits and shit articles in phoronix
<heat>
and then shittier articles that cite phoronix
<Cindy>
i don't even get x86 at this point
<Ermine>
That's phoronix
<Cindy>
it's a shit outdated architecture
<Ermine>
Well, atm processor is either x86 or slow
<Ermine>
iiuc
<heat>
you have some fast arm64 server processors
<Cindy>
yes
<Cindy>
arm64 is more power-efficient
<heat>
but i bet 10 ussd doller on how arm64 CPUs are all vulnerable to these attacks
<heat>
*or* slow
<Cindy>
lol, in what world?
<Cindy>
unless arm64 CPUs are just x86 CPUs with a translator
<heat>
this one
<heat>
do you think the backend is different?
<heat>
frontend is literally the only difference
<heat>
AMD zen was an ARM processor before it was x86
<Ermine>
Seems like you can't get speed without speculative stuff, and with speculative stuff you just can't control everything, am I right?
<Cindy>
heat: so can AMD make a m68k CPU that's as fast as modern CPUs?
<Cindy>
just with a different frontend?
<heat>
no because m68k is a shit architecture
<heat>
but for actual architectures, sure
<Cindy>
how dare you
<Cindy>
m68k is better than x86
<acidx>
:popcorn:
<nortti>
it's also very hard to make performant
<sham1>
heat: heresy
<sham1>
m68k was perfect
<heat>
fuck do you want sham
<nortti>
"ah yes, let me do two memory accesses per instruction" sentences dreamt up by the m68k designers
<heat>
i'll fly to finland and fight the shit out of you
<sham1>
no
<heat>
and then have a waffle with nortti
<heat>
actually me and nortti we'll fight the shit out of you
<heat>
whoop your ass
<Cindy>
nortti: that is a dumb assumption
<Cindy>
heat: 68060 could do better floating-point than the pentium could lol
<heat>
you got me
<heat>
that's why im running a pentium atm
<heat>
waiiiiiiiiit, im not running a pentium?
<sham1>
Pentium derivative
<heat>
yeah windows 11 is just an MS-DOS derivative
<sham1>
Yes. That's why it's shit
<sham1>
Among other things
<sham1>
Damn corpos
<nortti>
Cindy: aiui m68k allows a lot more memory accesses per instruction than even x86, and they can be dependent on each other, meaning a superscalar CPU would need to break the instructions up more aggressively (and thus do more tracking to make sure observed behaviour matches an in-order design)
<Cindy>
68068 was on par with the pentium, and it could do faster integer multiplications and bit shifting, plus allowing for floating point instructions to be used at any time
<sham1>
Not having superscalar is a feature
<heat>
good
<acidx>
the only nice architecture is the 69k though
<heat>
how is that relevant 40 years later?
<heat>
haha sex number architecture
<acidx>
I'm very mature
<Cindy>
sham1: 68060 was superscalar though
<sham1>
bah
<sham1>
Silly revisions
<sham1>
68000
<nortti>
I presume a dual-issue design similar to original pentium?
<Cindy>
yes
<nortti>
do you know what kind of IPC it can get in practice?
<bslsk05>
ieeexplore.ieee.org: Side-channel security of superscalar CPUs : Evaluating the Impact of Micro-architectural Features | IEEE Conference Publication | IEEE Xplore
<sham1>
Reject superscalar, embrace scalar
<heat>
reject superscalar, embrace linux kernel
<heat>
reject linux kernel, embrace sun and grass
<Ermine>
reject stuff, embrace kernal
<Cindy>
nortti: it could do ~177 MIPS @ 133 MHz
* Ermine
. o O (how many MIPS MIPS can do)
<sham1>
Also speculative execution booo
<nortti>
Cindy: ~1.3 sounds respectable, though does seem to be far from the theoretical 2 IPC a dual-issue design could provide. dunno if that is choking harder than the original pentium did though
<heat>
is valve on it? is that why it's taking so long
<nortti>
GeDaMo: that seems to be some kind of modern softcore
<Cindy>
that's a shit motorola 68000 derivative
<GeDaMo>
Yeah
<heat>
Intel officially launched the Itanium 9700 series processor family on May 11, 2017.[140][8] Kittson has no microarchitecture improvements over Poulson; despite nominally having a different stepping, it is functionally identical with the 9500 series, even having exactly the same bugs
<heat>
bug compat
<Mondenkind>
I want a subscalar cpu
<Ermine>
heat: but hey, it's 100% compatible
<Cindy>
Mondenkind: i want to eat cpu
<Mondenkind>
i want to eat u
<Cindy>
o.o
<Cindy>
i'm not very good to eat, full of fat and such
<heat>
sus
<heat>
i want onyx to get SUS certified
<heat>
Onyx is SUS hehe
<nortti>
it's really hard to find anyone have actual real-world IPC figures on p5
<Cindy>
among us is not funny
<nortti>
best I've found is an overview of the rules that prevent an instruction from being executed on the secondary pipeline