qubuepe24 has quit [Remote host closed the connection]
alexander has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
alexander has joined #osdev
netbsduser has joined #osdev
gog has quit [Quit: byee]
netbsduser has quit [Ping timeout: 248 seconds]
teardown has quit [Remote host closed the connection]
teardown has joined #osdev
msv has quit [Remote host closed the connection]
Dead_Bush_Sanpa1 has joined #osdev
Dead_Bush_Sanpai has quit [Ping timeout: 252 seconds]
Dead_Bush_Sanpa1 is now known as Dead_Bush_Sanpai
<Ermine>
i guess it's theoretically possible to provide some minimal Go runtime
<Ermine>
to implement "safe" part
<Ermine>
stdlib is not strictly required, though it will be very unidiomatic go
x64S has quit [Quit: Leaving]
GeDaMo has joined #osdev
msv has joined #osdev
bombuzal has quit [Quit: b0rk]
kfv has joined #osdev
hwpplayer1 has quit [Remote host closed the connection]
spare has joined #osdev
jedesa has quit [Remote host closed the connection]
jedesa has joined #osdev
goliath has joined #osdev
the_oz has quit [Ping timeout: 265 seconds]
kfv has quit [Remote host closed the connection]
kfv has joined #osdev
goliath has quit [Quit: SIGSEGV]
kfv has quit [Ping timeout: 252 seconds]
<ddevault>
who's the dork that wrote the Assembly page on the wiki with an Intel bias
kfv has joined #osdev
kfv has quit [Ping timeout: 244 seconds]
<zid>
Reality has an intel bias
kfv has joined #osdev
<Ermine>
most learning materials on assembly use intel syntax
<Ermine>
but then you get in the arm world and this dichotomy ceases to matter
<geist>
yep
<geist>
also once you get a few arhitecutres under your belt the dichotomy of intel and att also ceases to matter
<zid>
It still strikes me as insanely weird how attached people get to gas' intel syntax. It's a 40 year old hack.
<geist>
it's just like another architecture that's similar, you figure out how to translate it in your head
<geist>
i get used to it because that's what the tools use
<geist>
the tools i'm using at least, and all the code written using the tool, etc
<geist>
so stick with what you got
<geist>
and like i said it does't really matter once you have experience of one or two architectures or get more experienced with x86. it's kinda like writing the same algorithm in C and C# and java and python. you get used to the fact that the keywords are slightly different, etc
<geist>
but you just blat it out in whatever language, because once you learn one the others are easier
<geist>
also should point out that the intel manuals dont really even use their own syntax. it's not really precisely what you see in nasm or whatnot
<nikolar>
zid: yeah, if you want intel syntax, use a proper intel syntax based assembler
heat has joined #osdev
<zid>
what does icc use? :P
<nikolar>
does it matter :P
<zid>
(intel doesn't even have syntax that works, 'intel syntax' in reality is nasm syntax)
<nikolar>
ye
<geist>
yah
<geist>
note there is similar nonsense with other old arches like 68k, we're just not sitting around arguing about it because we're mosty not writing that code
<heat>
icc is clang nowadays
<geist>
only reason is there's some damn 40 year old arch we're still fucking with
<nikolar>
geist: were there multiple assmeblies for m68k?
<geist>
heat: oh interesting, they rebased it on clang/llvm huh?
<heat>
yep
<geist>
nikolar: yeah. i discovered that when i started porting LK to 68k
<nikolar>
oh i only know what gcc spits out
<zid>
gas is like, *mostly* an okay x86 assembler
<geist>
there's kinda a similar thing where gas uses one syntax (close to AT&T of course) and some other stuff, including the motorola manuals uses another
<zid>
some stuff is broken, some stuff is missing
<geist>
it's actually almost more different than AT&T/intel, since 68k has a lot more exotic addressing modes
<nikolar>
geist: fun fact, pdp-11 objdump dissassembly is broken
<geist>
oh yeah?
<nikolar>
shows immedate and deferred addressing modes in the same way
<nikolar>
kek
<zid>
lss doesn't work at all sizes, there's very little capacity to pick encodings (which is important for say, relocations)
<zid>
etc etc
<geist>
AFAIK all of the DEC hardware used pretty consistent syntaxes
<geist>
and really AT&T is largely based on it
<zid>
If only VAX had better syntax to begin with :P
<geist>
it was actually highly regular for VAX
<nikolar>
vax was a highly regular isa to
<geist>
it was because x86 is waaaaay more irregular than vax
<zid>
Teleport into the future and don't need really easy to parse one pass syntax!
<geist>
so sort of applying the same logic to x86 ends up with a little bit of a mess
<nikolar>
i mean it works
<nikolar>
it's fineee
<heat>
i'm a big AT&T stan
<zid>
x86 was close enough to make them attempt it, but far enough away that it ends up.. a bit weird
<heat>
it is UNIX tradition
<heat>
the spirit of UNIX
<geist>
some of the weird stuff where you can dereference a label without any bits is a AT&T ism. i think it is more regular for DEC
<geist>
but yeah i only really work with AT&T beacuse that's what i use from a day to day basis
<zid>
the dereference a label shit capstone syntax does drives me nuts
<nikolar>
heat: AT&T AT&T AT&T AT&T
<zid>
(AT&T is worse, but capstone is OTHERWISE really sane)
<heat>
the ghost of UNIX past will haunt you if you ever write a UNIX in intel syntax
<zid>
heat: wooOoOooooo my spooooky long.asm
<nikolar>
geist: which one is immedate and which one is deferred
<nikolar>
mov r0, $fffff001
<nikolar>
mov r0, $1
<nikolar>
kek
<zid>
gas is stupid about labels on mips too
<geist>
oh heh. well file a bug!
<geist>
the worst is POWER, the syntax is highly hard to read because everythign is implicit
<nikolar>
it does show `mov r0, $fffff001 <_bss_e+0xffffdf83>`
<zid>
it has lu/la/lui/etc and it matters which you use when you're using a label.. else you just get a 0
<nikolar>
but i completely overlook that when reading code, it's just noise
<geist>
you get stuff like `rlwinm 1, 2, 3, 4, 5`
<geist>
what is what? register? immediate? you should know!
<nikolar>
geist: are registers just numbered
<nikolar>
so you say mov 1, 2
<zid>
r0, 1, r2
<geist>
yeeep
<zid>
My final offer
<nikolar>
oh no
<geist>
gas at least lets you put a 'r' in there and it has to be at least at the right spot
<zid>
oh good
<nikolar>
GAS GAS GAS
<Ermine>
MASM MASM MASM
<zid>
"Manual is wrong, but gas is wrong in a different way" is my usual take :P
<geist>
but otherwise POWER the mnenomic completely describes all of the operands
<geist>
so the types are all implicit
<heat>
clang as!!
<heat>
clang as actually has way better error reporting than gas
<geist>
yah i'm warming up to it
<zid>
does it support lss
<heat>
with colors too!
<nikolar>
zid: what's lss
<zid>
clang added better errors and colours, and then gcc got them
<geist>
a few years ago when we got started with zircon it was more annoying, but via a few years and a lot of bug fixes by us its actually pretty great
<bslsk05>
c9x.me: Liberation: x86 Instruction Set Reference
<heat>
similarly lld is way better at error reporting than binutils
<geist>
the fuchsia team files and fixes a *lot* of bugs with the toolchain in general
<nikolar>
zid: kek
<geist>
and lots of stuff like that we would bump into and then roland would get that fixed
<geist>
and since he's a god of toolchain and libc folks they listen to him
<heat>
thank mr roland
<zid>
lss eax,FWORD PTR ds:0x0
<geist>
well, hey i mean dont get too upset about 'lss' mang
<zid>
:D
<zid>
FWORD!
<heat>
geist, how's the fuchsia libc coming along? do you still have some musl left?
<nikolar>
the heck is a FWORD
<zid>
far
<nikolar>
oh
<heat>
FUC
<heat>
or that
<zid>
fuckboi word
<geist>
working on switching to the new llvm-libc actually yes
<nikolar>
what's a llvm-libc
<heat>
sad :(
<heat>
it's a terrible thing
<geist>
i dunno where that's at, but theres been some amount of work getting the llvm-libc up to snuff. and actually there's some work on getting it to be embeddable, etc
<heat>
do not look into it
<geist>
i have no idea if it's any good, etc. no idea
<nikolar>
heat: you can's say that and expect me to not look into it
<heat>
C standard library header files are autogenerated from LLVM tablegen descriptions
<geist>
i suspect it's hyper-overcomplicated as smart people tend to do
<heat>
like, seriously.
<heat>
it's google'd to shit yeah
<nikolar>
:|
<geist>
yeah, that's what happens when google gets involved
<geist>
it doesn't mean it's not *good* per se, but doen't mean it's fun to work with i bet
<Ermine>
why not bionic?
<heat>
because
<geist>
i forget. there was a good reason at the time
<heat>
i mean truly bionic sucks
<heat>
it is a huge hack
<geist>
that may have been it
<geist>
musl at least we were able to slam into place pretty quickly
<nikolar>
heat: how's it a hack
<heat>
BSD source orgy that's incomplete and half of it is written in C++
<nikolar>
i've never looked into android much
<geist>
but honestly i would have started with BSD libc but folks weren't interested when we got started
<geist>
i am utterly surprised (maybe i shouldn't be) at the fact that basically zero of my co-workers at google that i've talked to even know anything BSD exists
<nikolar>
:|
<heat>
wat
<geist>
i must be just too old, but 9/10 times i mention something like 'and freebsd does this' i get a blank stare
<nikolar>
osdev people too
<zid>
I've never used a BSD to do anything
<nikolar>
zid: but you know it's a thing
<zid>
I mean, in the same way I know santa is a thing
<geist>
i say this literally as i upgrade my pentium 4 machine from freebsd 14.1 to 14.2 :)
<nikolar>
you wouldn't give a blank stare if someone said "freebsd does this"
<zid>
I've *heard* from people it supposedly exists and supposedly has certain characteristics, but I'm too old to believe it
<nikolar>
geist: ooh fancy
<zid>
and I'd look at them funny if someone kept bringing up santa lore when I was talking about stuff
<geist>
haha
<geist>
ahahaa
<nikolar>
lol
<heat>
FREEBSD DOES NOT EXIST WAKE UP SHEEPLE
<geist>
but i bring it up sometimes at work becaus ei can say something like 'freebsd does X for riscv because' and it's BSD licensed
<zid>
geist: You might have better luck with koala facts instead
<zid>
"They've all got chlamydia!"
<heat>
geist, dont you have some older people involved
<geist>
but really at google there's linux and everything else
<heat>
roland only knows what gnu hurd is, obviously
<geist>
heat: well sure, but.... most people are younger almost by definition
<nikolar>
:(
<zid>
I think everybody is younger than you, geist
<geist>
yeah i ask him questinos to tie break stuff
<geist>
i actualyl asked him the other day about AT&T syntax, etc
<nikolar>
at&t da best
<heat>
found the monopoly enjoyer
<zid>
working in tech is difficult because you have to resist beating your co-workers to death with your shoe for birthing various pieces of software
<geist>
zid: but yes, that is also something i'm keenly aware of
<nikolar>
zid: kek
<geist>
dont go on about old shit that no one cares about because you'll become irrelevant
spare has quit [Remote host closed the connection]
<geist>
i've seen it happen, so i try to move with the times a little bit at least
<heat>
hey glibc is GOOD
<heat>
>heat has been banned from #musl
<geist>
well if they ban you for saying that? fuck em
<geist>
that's like being on any discord channel
<zid>
heat: That's weak, go tell ##c++ that actually you quite like #define
<heat>
I LIKE C WITH CLASSES
<heat>
banned from r/cpp
<zid>
classes are one of the worst parts lol
<geist>
yeah ban classes from C++
<zid>
agreed
<heat>
structs only.
<geist>
it's all about class warfare
<geist>
oh shit actually with structs you're pretty uch okay :(
<geist>
i distinctly remember a file in beos that was
<zid>
They fuck up the compile time encapsulation, which causes the fucky ABI and recompilation time issues. Plus all the other complex crap is hung off them too, like really complicated constructors etc
<zid>
remove classes and C++ is kind of usable
<geist>
`// forgive me father for i have sinned\m #define private public`
<geist>
\n
<heat>
haha
<geist>
then it included some other header
<heat>
#ifdef CONFIG_KUNIT
<heat>
#else
<heat>
#define KUNIT_PUBLIC public:
<heat>
#define KUNIT_PUBLIC private:
<heat>
#endif
<nikolar>
loller
<zid>
heat: I got all 50 stars for the first time in AOC btw
<heat>
nice, congrats
<heat>
i got 0 for the Nth time
<zid>
You'll figure out how to solve simple mazes eventually heat
<zid>
we believe in you
<geist>
follow the left wall heat follow the left wall
<nikolar>
kek
<zid>
heat: Hardest level this year was 'Here's the netlist for a full adder, 4 wires are connected wrong, find them'
<zid>
nobody wrote any code for it cus it was too hard to solve generically, and you had to figure out what the input looked like and your code would have ended up 'find these specific bugs'
<zid>
so everybody solved it on paper first, then optionally wrote some code to replicate it
<bslsk05>
github.com: llvm-project/libc/startup/linux/x86_64/start.cpp at main · llvm/llvm-project · GitHub
* heat
barfs
<nikolar>
lol
gog has joined #osdev
<zid>
I love the "interfacing C and asm wrt the stack pointer is super sketchy" parts of doing embed
<zid>
"better hope the compiler doesn't decide to make a local!" and other stuff going through your head
<zid>
build breaks on -O0
<nikolar>
just write _start in assembly
<nikolar>
you're welcome
<heat>
yeah that's what musl does
itszhadanjun has joined #osdev
<heat>
__asm__(/* a little _start bootstrap */)
<zid>
but what if you want to shave the 'call' out of your interrupt handlers!
<geist>
this is a fairly constant battle i fight at work. lots of folks want to replace every line of asm with some equivalent complicated structure in high level languages
<zid>
so no f: push non-abi-saved-regs; call real_handler; pop em; ret
<zid>
iret
<geist>
to a lot of folks asm is intrinsically the worst thing you can possibly do. it's te opposite of languages like rust or whatnot
<geist>
like every line of asm is a risk
<Ermine>
sometimes things work nicely in C, e.g. armv7-e boot code
<nikolar>
geist: lol
<geist>
the flip side that i say a lot is asm doesn't change based on the toolchain
<nikolar>
Ermine: that's because armv7-e was specifically designed like that
kfv has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<geist>
for simple messy things you do it once and then it's done. some things are just better served with single pass, procedural assembly
<Ermine>
nikolar: maybe
<geist>
armv7-m, not -e
<nikolar>
that
<nikolar>
Ermine: almost certainly
<Ermine>
oh yeah
<Ermine>
re -m
<geist>
just to be pedantic
<heat>
geist, what kind of asm lines can you replace with high level languages?
<heat>
like, memcpy?
goliath has joined #osdev
<heat>
besides entry/exit points and memcpy/memset i dont think i have much asm at all
jedesa has quit [Quit: jedesa]
<heat>
apart from inline asm, i do funky stuff for %gs
<zid>
asm("hlt");
<geist>
well, lots of start.S style stuff. setting up the GDT, settng up the IDT, configuring the gs pointer, setting the stack pointer, etc
<geist>
bootstrapping a cpu through real through protected into 64bit mode
<heat>
hlt can TRIVIALLY be replaced with a for (;;) zid
<heat>
just make sure it isn't in C++
<zid>
jmp -2 and hlt are *slightly* different
itszhadanjun has quit [Quit: itszhadanjun]
<heat>
do you have any proof of that?
<geist>
it's not whether or not you can do a lot of these things in C/C++ if you try but if you're going to build some infrastructure to do it in C/C++ and then do it exactly once what's the point?
<heat>
maybe from the mythical "FreeBSD" systems
<geist>
lots of typing and then you caall the function/etc once
<geist>
sometimes things are simpler to just do in asm, get it done, move on. never touch it again
<nikolar>
heat: the proof is that my cpu runs 40C cooler with hlt :P
<geist>
and nmore to the point if it always *was* done, has been working, why bother replacing it?
<zid>
heat: hlt was created by big bitcoin to create more spare cpu power for mining viruses
bauen1 has joined #osdev
<heat>
geist, totes. though i do paging in C now
<zid>
real men just have 100% cpu use at all times regardless, if you need to hlt you should just start more programs
<heat>
but i have to be really fucking careful
<geist>
i mean for example: you can build a complex class that completely encapsulates all of the GDT descriptors, GDT table, builds one for you, lets you do it entirely in constexpr
<heat>
running C with a batshit insane environment is like stepping on eggshells
<geist>
takes about 1000 lines of complicated ass C++ with templates
<geist>
then you just call it once to generate a GDT for you
<zid>
To be fair, that's what C++ excels at, describing ad-hoc domain languages with custom types
<geist>
where you could have just done once
<zid>
So why else use C++ at all if you're not going to do that everywhere? :P
<heat>
no macros no enums just rawdogging a GDT in hex
<nikolar>
so instead of writing a few lines of c to set up the gdt, you write 1000 lines of c++ template nonsense only to call it once :P
<geist>
right, that's the point: applying the same tool to all problems isn't necesarilly the cleanest solution, but it depends on what you consider 'clean'
<geist>
to a lot offolks that's clean becaus eyou can write unit tests, etc
<zid>
It's a shame that it doesn't .data all this though
<geist>
which i think i'm going to change. i have a branch where i'm adding x86-smp and i'm thinking of switching to one per cpu
<nikolar>
zid: i am sure you really need those few nanoseconds that you would've saved :P
<geist>
for the moment we are using this style for zircon though, one TSS per cpu
<zid>
I wonder if mcmodel helps
<heat>
that implicitly limits you to ~64K/16 cpus :(
<geist>
yeah
<heat>
LITERALLY UNUSABLE
<heat>
PESSIMAL
<heat>
CRAPPER
<geist>
the thing working against us is zircon has full 64k GDTs for Reasons
<geist>
so we'd have to burn 64k per cpu
<zid>
I guess it can't avoid this unless it knows where .data is, for things like mov QWORD PTR tss[rip+4], OFFSET FLAT:kernel_stack+4096
<zid>
which it can't do until link time
<zid>
And I'm not sure gcc can spit out a 'data to data relocation for some data I don't know the address of really'
<heat>
why does zircon have 64K gdts?
<geist>
during bootup the template GDT is copied to a large 64K vmo which is mapped into the kernel
<geist>
heat: /me whispers... VMX
<geist>
fucking intel bugs
<heat>
lol
<heat>
a bug when you are the hypervisor?
<geist>
there's some subtle detail where when the cpu enters or exits vmx (i forget) it resets the GDT limit to 0xffff
<geist>
it's not really a bug, just a silly design error
<heat>
i dont think i've seen that in linux
<heat>
but i didn't really look
<geist>
basically it only saves the LGDT base when you enter a guest, and thus restores the base + 0xffff when you come out
<zid>
mov WORD PTR e[rip+45], -32631
<zid>
mov BYTE PTR e[rip+47], dl
<zid>
I lied, gcc is shit
<geist>
you can re-LGDT as soon as you exit, maybe linux does that, but it's expensive
<geist>
so we just set up a large 64k GDT with a bunch of null entries all the way out so we dont have to ever re-LGDT
<geist>
i forget it may do the sam ething to the IDT
<geist>
that being said i think we only really use the first 4K of that GDT VMO since the rest of teh 60K is unpopulated, so the VMM just maps the zero page over and over again
<geist>
and i think it's not possible for the cpu to write back to an invalid entry in any way (ie, no active bit or whatnot)
<zid>
I think what I want is like, relocation bytecode
<zid>
instead of constexpr classes
<zid>
so I can say "I want the 4th and 7th bit of this address in these 2 bits" or whatever, like the silly HI() and LO() keywords you end up needing in mips assembly, but.. let me do whatever I want
<geist>
:lo12:
<geist>
i cant not read that as 'lol 2' but it's 'lo 12' in arm asm for the same thing
kfv has joined #osdev
<zid>
I thought it was a discord sticker
kfv has quit [Client Quit]
<zid>
I've actually wanted this before, but I wanted it for generating a checksum in a header
ionut_f has joined #osdev
<kof673>
<reads backlog> > In northern Siberia, the heavenly reindeer, symbolized by the big dipper after cross-referencing, hercules beats up the reindeer/bear and threw santa's sleigh up there because it killed his father
<kof673>
you have to cross-reference <shakes head>
<bslsk05>
git.kernel.org: KVM: VMX: Fix host GDT.LIMIT corruption - kernel/git/torvalds/linux.git - Linux kernel source tree
<heat>
this is terrible but i guess isn't necessarily slow?
karenw has quit [Quit: Segmentation Fault (Core Dumped)]
KarenTheDorf has joined #osdev
<ring0_starr>
should it ever be possible to boot a VBR by itself?
karenw has joined #osdev
<heat>
ok sadly lgdt is serializing but it shouldn't be *that* noticeable
<heat>
between the cmpxchgs and smp_mb and all that shit you go through in normal system operation
<ring0_starr>
is there any sort of guarantee of ds:si pointer validity when the VBR starts execution, or rather, is there any convention to signify that it is not valid other than ds == 0 && si == 0? i read something about this whole convention being broken with >win10 MBRs
KarenTheDorf has quit [Quit: Segmentation Fault (Core Dumped)]
goliath has quit [Quit: SIGSEGV]
npc has quit [Remote host closed the connection]
the_oz has quit [Ping timeout: 276 seconds]
the_oz has joined #osdev
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 244 seconds]
the_oz_ has joined #osdev
the_oz has quit [Ping timeout: 252 seconds]
agent314 has joined #osdev
karenw has quit [Quit: Segmentation Fault (Core Dumped)]
karenw has joined #osdev
karenw has quit [Ping timeout: 248 seconds]
hwpplayer1 has joined #osdev
hwpplayer1 has quit [Remote host closed the connection]
<gog>
afaik there's no convention
<gog>
disregard
<heat>
delet this
<gog>
there are two coventions
<gog>
ds:si points to the MBR partition table entry of the partition whose VBR is being invoked _sometimes_
<gog>
but afaict it's up to whoever is writing the MBR
netbsduser has joined #osdev
getz has quit [Ping timeout: 244 seconds]
getz has joined #osdev
fedaykin has quit [Quit: leaving]
fedaykin has joined #osdev
agent314 has quit [Ping timeout: 244 seconds]
agent314 has joined #osdev
karenw has joined #osdev
hwpplayer1 has joined #osdev
hwpplayer1 has quit [Remote host closed the connection]
melnary has quit [Read error: Connection reset by peer]
melnary has joined #osdev
ionut_f has joined #osdev
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
gildasio has quit [Quit: WeeChat 4.1.2]
cloudowind has quit [Ping timeout: 244 seconds]
cloudowind has joined #osdev
goliath has joined #osdev
muffin has joined #osdev
agent314 has quit [Ping timeout: 246 seconds]
<geist>
i wonder if it ever even was a convention or was originally just left over from the previous stage code and someone took it as a convention
muffin has quit [Client Quit]
<gog>
given the history of DOS, it seems likely that the latter is the case
<gog>
conventions of "better not fuck with it"
kevidryon2 has joined #osdev
<gog>
this is an ancient practice of our people (software engineers)
<karenw>
You just described like... half the PC boot process lol
<karenw>
"DOS did it, so Windows does it, so everyone does it"
<geist>
pretty much
<zid>
if windows jumped off a cliff would you do it too!?
<zid>
*looks at tech industry* ah, yes, yes they would
<sortie>
I found a bug in my ppoll(2)'s EINTR behavior so I carefully read POSIX, then wrote unit tests for every edge case I could think of, ran my os-test lab on every single Unix, studied the results, interpreted POSIX, and then I fixed my implementation to have the best behavior. I even found bugs in DragonflyBSD, Hurd, and Linux in the process. :)
ionut_f has quit [Ping timeout: 244 seconds]
<sortie>
https://sortix.org/os-test/#signal-ppoll-block-close ← It's a super valuable facility for osdev work to be able to quickly write a bunch of unit tests, easily run them on every OS, and learn how things are supposed to work in cursed edge cases
<bslsk05>
sortix.org: os-test
<zid>
maybe someone will hire you as a test engineer
<geist>
it does bring up the question for purely esoteric reasons: precisely what does the boot sequence on OS/2 look like? it presumably uses MBR too. does the OS/2 main system always have to be in the first partition, presumably HPFS?
<geist>
etc
<sortie>
zid: I did get laid off as an engineer running the test infra lol
<geist>
does it use a standard dos MBR that selects based on the active bit
<geist>
sortie: so now you're gonna captain ahab unit tests?
<sortie>
geist: look we just gotta test whale(2)
<karenw>
xcb_harpoon_whale: Harpoons a whale.
<sortie>
geist: But I did get into talks with the rust people about building a common POSIX test suite
<heat>
sortie, fwiw i don't think you're getting the linux behavior fixed
<the_oz_>
They used to paint boxes grey and lines yellow at a dock in norway
<heat>
we dont break ABI is more important than fixing slight POSIX incompat
<the_oz_>
painter one day sets his yellow paint on the grey box to paint the line
<sortie>
heat: The signal is delivered if no other events are pending. I see no reason why fixing this would break anything, after all the signal is explicitly unmasked. The bigger question is whether we're dealing with a ppoll fast path that they'd rather not make slower.
<the_oz_>
thast's how the dock gained yellow boxes randomly, to cover up the mistake and no one knows why. they maintain it thusly from then on
<zid>
linux fixes things nobody uses anyway
<karenw>
Linux's policy is "don't break the user/kernel interface, and work around it in libc"
<sortie>
heat: Plus after all, every other OS does deliver the signal (besides dragonfly), and POSIX is quite clear as to the semantics of ppoll. It also creates a problem where a process that wants to handle signals during a ppoll sleep (for safety) might not get the signal for a while if there are enough incoming traffic that ppoll never actually sleeps
<karenw>
Unless it's the dri subsystem, where it's "Don't break the open source userspace lib but any private impls can suck it"
netbsduser has quit [Ping timeout: 252 seconds]
<sortie>
karenw, indeed, but also this particular issue cannot be fixed on the libc because ppoll is designed to be an atomic sigprocmask in the kernel
<karenw>
So if it's broken, it would need to stay broken. At best you'd get a ppoll2 syscall added that does it right?
<zid>
it doesn't need to stay broken
<zid>
It only stays broken if it breaks someone else
<zid>
which seems unlikely
<karenw>
AFAIK Linux's policy is "assume all kernel behaviour is assumed by someone somewhere", with the exception of the dri subsystem.
<sortie>
karenw: I suggest you look at the tests and the data. ppoll does deliver signals if it goes into a sleep. It's only that there is a fast path that doesn't deliver signals if any actions were pending. But such actions could easily not have been pending. So it's really more of a reliability question, and not something that would in practice break anything
<the_oz_>
You could by convention decide that "poll" implements itself as "latest stable version number" by indirection
<the_oz_>
thus poll expands itself to poll_3 of 3 versions etc.
<karenw>
the_oz_: That's what (g)libc does yeah.
<sortie>
It's also not a big problem because if the process handles all the incoming events, it will likely get back to a sleep state soon, and process the signal there. It does open the process to a denial of service where signals might not be delivered.
<the_oz_>
oh I didn't know that
<zid>
There was a case where someone improved the performance of something so massively that it caused a race in a real program and the patch was reverted though :P
<karenw>
For example see the various x86_32 apis that got updated to 64-bits over time. (UIDs, file sizes, time_t). From a normal application's pov they just call the same function in glibc, and it redirects them via #defines or versioned sysmbols to the right syscall. But the original 32-bit syscalls are still there and have never changed.
<heat>
sortie, i don't think that argument will slide though
<heat>
POSIX is linux's toilet paper
<karenw>
POSIX is a guideline. But where the guidelines intersect with reality, reality wins.
<sortie>
My data is reality. :)
<heat>
no, your data is fiction
<zid>
reality wins in terms of it gets to ignore posix :P
<heat>
almost literally no one cares about any of those systems except linux and _maybe_ freebsd (for netflix)
<sortie>
I would like to cite my reaction when I found this issue
<sortie>
<sortie> I may have found a bug in Linux <sortie> Or, as they call it, a feature
<heat>
or maybe Big NetBSD rules the world
<Ermine>
aren't there posix-certified linux distros
<sortie>
I'm still mad I don't have z/OS
<heat>
but uhhhh im not even sure BSD is real
<heat>
Ermine, no i dont think so
<heat>
if there are, it says something about the test suite and the hacks implemented
<sortie>
Besides those POSIX test suites are ancient (POSIX 2001) and outdated
<heat>
adelie's musl patches made me want to cry
<the_oz_>
kek, freebsd will forever hasng onto that selling line huh. Even though it hardly matters even when it was
<nikolar>
heat: why's that
<the_oz_>
the dame genius that chose freebsd for the servers also chose silverlight for the client
<zid>
nikolar don't listen to heat he eats bananas for the shape
<nikolar>
the_oz_: what's a silverlight
<karenw>
Windows is POSIX.1 certified. (Just with, you know, the absolute bare minimum feature set of POSIX.1)
<zid>
gotta divide your old size by your newsize comparisons
<nikolar>
lol
<zid>
and not have () around the thing for the if
<karenw>
It escapes the newline in the preprocessor
<zid>
It's a function not a multiline macro
<karenw>
But it seems pointless in that use case
<mcrod>
hi
<kevidryon2>
hello
<nikolar>
and where's the preprocessor karenw
<the_oz_>
what's the F# thing? Not F# I can't remember
<zid>
I refuse to believe this compiles
<mcrod>
i'm taking a poll
<mcrod>
how many of you are sick
AFamousHistorian has joined #osdev
<zid>
I was, briefly, no longer
<mcrod>
i have counted 18 people so far
<karenw>
nikolar: Yes, it is well defined to do absolutely nothing but make error message line numbers more inaccurate.
<zid>
18 in 10 billion? pretty good
<kevidryon2>
you mean ill, like a cold?
<the_oz_>
I'm remembering a black hole and only thinking oof things arount it
<nikolar>
karenw: how the heck does adding \ to my ifs unnecessarily make better error messages
<heat>
>inaccurate
<zid>
well it tells you unexpect \ on line 38
<zid>
cus \ isn't a token in C
<mcrod>
kevidryon2 yes
<mcrod>
i feel as though i've been run over by a bus, a shit ton of people have tested positive for the flu or COVID, not me though :)
<zid>
gcc fucking accepts this though I just tested it
<kevidryon2>
yea i was sick a few weeks ago
<zid>
It just strips \\(|\r)\n
<zid>
wtf gcc
<karenw>
nikolar: The opposite. It would report an error on the second line of the expression to be on the first line because the line got removed by the preprocessor (assuming the CPP and the C-compiler proper are truly separate passes)
<karenw>
Which is worse than not having that \
<nikolar>
oh i read that wrong
<zid>
there's no preprocessor involved h ere
<nikolar>
you're right
<zid>
gcc is just being silly
<nikolar>
try clang or something
<Ermine>
heat: lmao
<zid>
I assume there's just a "global" 'concat lines ending in \' pass that doesn't require us to be inside a preprocessor directive
<kevidryon2>
i often switch between gcc14 and clang to diagnose errors in my code
<karenw>
zid: Yes, exactly
<zid>
well that ain't C, burn gcc and clang to the ground
<zid>
also, thanks clang
<zid>
warning: 'size' argument to memset is '0'; did you mean to transpose the last two arguments? [-Wmemset-transposed-args]
* zid
checks the definition of his memset
<zid>
yea whoops :D
<zid>
It was already zero so it was just a no-op either way
<zid>
and showed that gcc and clang both accepted it
<karenw>
IMHO gcc's preprocessor is wrong here
<zid>
and reported back here
<zid>
Yea they're both wrong
<zid>
it should only apply on a line starting with #define
<zid>
or maybe #if
<zid>
I haven't checked
<karenw>
I don't think so. Pretty sure '\' followed by '\n' in the source character set is required to be processed by the preprocessor regardless of where it is. It's just not useful in any way.
<zid>
Each instance of a backslash character (\) immediately followed by a new-line character is deleted
<zid>
fiine, it's allowed
<the_oz_>
it will yell ast me for breaking it
<zid>
It says it *after* the preprocessing part (preprocessing translation unit) and in the translation unit part
<zid>
but then it says #include is processed, so whatever
<zid>
it's still part of the preprcoessor, but it doesn't limit it to being inside a directive
<karenw>
zid: Yup, that's my understanding.
<sortie>
heat: hmm most of those adelie musl patches seem fine although yeah the renameat stuff is sketchy since you lose atomic properties when libc tries to fix up the kernel like that.
<zid>
musl is insane still, but gcc is now begrudgingly absolved
<zid>
it was *told* to allow this insanity
<heat>
that isn't musl code
<heat>
it's an adelie patch
<zid>
what's adelie
<zid>
or who
<zid>
you're right though, musl source would be entirely single character names
<zid>
and formatted even weirdlerlrer
<nikolar>
adelie is a distro iirc
<heat>
its a linux distro based on musl that's trying to be POSIX compliant because lol lmfao
<heat>
this particular person thinks malloc is bad and shouldn't work well from multiple threads because of opinionated software opinions
<nikolar>
> and shouldn't work well from multiple threads
<heat>
and, hey, i agree, i am also never wrong never ever everyone else is wrong and i am right
<nikolar>
eh?
<sortie>
malloc might actually be a problem in some of those system calls because they're supposed to be async signal safe
<nikolar>
is the whole of malloc behind a mutex or something
<karenw>
malloc probabally is bad and probabally doesn't work well from multiple threads. But probabally != intentionally shouldn't
<heat>
malloc scalability
<heat>
on musl, yeah
<kof673>
> im not even sure BSD is real earth used to have 2 hemispheres...just put the trident in the underworld/abyss :D
<kof673>
down there with the vms shark
<heat>
malloc has been a musl problem FOREVER
<kof673>
eyeing the penguin
<karenw>
Windows has a whole custom heap API, and then the C lib just wraps a big default heap with a mutex iirc. Maybe it's got a bit cleverer since I was at uni.
<heat>
and the answer is always to get stuffed, either write the program as we want you to, or dont use musl malloc
<karenw>
And cared about Windows C/C++ development
<heat>
basically "have a main thread to allocations and dispatch to worker threads" and anything else is HARAM
<zid>
good news btw
<zid>
my hard drive has now been powered on for 15 years
<karenw>
heat: I mean, that's a good pattern in general.
<nikolar>
zid: congrats
<karenw>
zid: Maybe you should update your hardware slightly more often?
<zid>
karenw: It still works fine?
<nikolar>
at least backup while it still works
<zid>
It's a 1TB black, so it's faster than my 4TB red
<Ermine>
zid: just have a spare drive
<zid>
which has all my pirated goat porn
<karenw>
My 10 year old laptop is still going strong here though. Except when ubuntu breaks the drivers in an update (but mainline mesa works fine so IDK what they did)
<zid>
I have a spare ssd
<zid>
if I need to break its seal
<Ermine>
nice
<karenw>
My 1TB black from about 15 years ago had 0.1 bitcoin on it. It's in a landfill somewhere in sheffield or birmingham, uk.
<zid>
samsung sent me it as an RMA
<zid>
karenw: I spent all mine
<zid>
My arcade controller is worth about $80000 now
<zid>
do they take returns?
<zid>
oh, madcatz went out of business?dang
<karenw>
Minded lovingly by hand on a single Radeon HD 6870 HD.