channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev2&y=23&m=3&d=1
00:02:00 <klange> Something sounds seriously wrong with your compiler.
00:03:00 <heat> nope
00:03:00 <heat> retried with clang, same long ass compile time for some files
00:04:00 <klange> `-E | wc -l` is only 10k lines; there are no shenanigans at play
00:04:00 <heat> also it doesn't fully work with clang atm
00:05:00 <heat> obj_numeric.c chokes up because __builtin_floor() calls floor()
00:05:00 <klange> LDLIBS=-lm CC=clang make
00:06:00 <heat> that's not how the meson build works :)
00:06:00 <klange> then just link with libm in general, this sounds like a you problem
00:07:00 <heat> why?
00:07:00 <epony> the colon parenting thesis is a failure from the initial thinko, only polips there
00:07:00 <heat> I don't think the makefile does
00:07:00 <heat> you calling __builtin_floor seems like you're hoping you don't have to call floor()
00:08:00 <heat> which seems to work for gcc and not clang
00:10:00 <heat> ... now the build is a good bit faster
00:10:00 <heat> confusion.jpeg
00:10:00 <klange> were you burning all your CPU cores with something else?
00:11:00 <klange> > laptop
00:11:00 <klange> Maybe you were power throttled.
00:11:00 <heat> i don't think so
00:11:00 <heat> compiler.c is now down to 3.9s
00:12:00 <klange> I should just replace that __builtin_floor with a standard ieee double floor implementation, I already have an implicit requirement for ieee floats elsewhere...
00:12:00 <heat> why not just a cheeky -lm?
00:13:00 <klange> It is literally the only thing that would pull in lm (without `import math`, which is a shared object module) and it's just to get int//float to work.
00:14:00 <klange> And "LDLIBS=-lm make" _is_ my cheaky `-lm` ;)
00:15:00 <heat> fwiw some libraries don't actually have the separation
00:15:00 <klange> Yes, like mine.
00:15:00 <heat> so libc pulls in all of libm
00:15:00 <moon-child> why not just always link libm?
00:16:00 <heat> python seems to
00:16:00 <klange> CPython has a lot more integrated libm stuff.
00:21:00 <heat> I don't think you would lose much by bringing in libm
00:21:00 <heat> static just brings in that single func, shared should demand fault ~only the floor func
00:27:00 <klange> It's a matter of principles - being able to say the core interpreter requires only a minimal libc.
00:42:00 <heat> klange, testing if -lc has it and gnu-lib'ing your own is an option
00:43:00 <heat> particularly in meson. make may be more complex
00:43:00 <heat> (you could also switch to AUTOCOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOONF)
00:43:00 <klange> I could jump off a briodge.
00:44:00 <heat> jumping off a bridge over using autoconf is a valid option
00:45:00 <heat> *opinion
00:46:00 <klange> I thought I mentioned this in the readme or docs somewhere but I guess not, but my approach here really is "if the build complains about floor, try adding LDLIBS=-lm and see if that helps". If you would like to automate that process for the Meson build, feel free.
00:49:00 <moon-child> https://files.catbox.moe/4a4sxx.png
00:50:00 <klange> That single panel strip has a wikipedia article. https://en.wikipedia.org/wiki/Cow_Tools
00:53:00 <heat> moon-child, you're incredibly based
00:56:00 <klange> A quick way to check if __builtin_floor works sufficiently would be to try to build 'int main(int argc, char * argv[]) { return printf("%f\n", __builtin_floor(atof(argv[1]))); }' and see if it fails to link. That covers both `__builtin_floor` being inlined and libc having `floor`.
00:57:00 <klange> and shit like that is how any configure script, autoconf or not, essentially works
00:58:00 <mrvn> and that should really be something that is provided pre-computed by the OS
00:59:00 <klange> that one is a bit... esoteric
00:59:00 <klange> but plenty of other stuff, yeah, there could definitely be a database of all the things a configure script would care to look for
00:59:00 <mrvn> well, half. having math stuff in libc isn't that uncommon.
00:59:00 <mrvn> or math stuff available by the FPU
00:59:00 <klange> just take the most complicated configure script and store its cache somewhere
01:00:00 <heat> surely you mean AC_CHECK_FUNC
01:00:00 <mrvn> klange: yeah. a os/arch/system cache for autoconf tests would be nice.
01:01:00 <heat> https://github.com/kuroko-lang/kuroko/pull/38/files#diff-30d8f6be6320feeacf686be94f48c70869b52630e01ea625f0f15adc0d57c3e4R11 cleeeeeeeeeaaaaaaaaaaaaaaaaan
01:01:00 <bslsk05> github.com: Add meson build system support by heatd · Pull Request #38 · kuroko-lang/kuroko · GitHub
01:02:00 <heat> i could also actually check if __builtin_floor works but damn that would kind of suck wouldn't it
01:02:00 <mrvn> in this case gcc should provide autoconf tests for all builtin functions that may be problematic.
01:03:00 <mrvn> i.e. builtins that actually aren't builtin but make library calls.
01:11:00 <klange> heat: https://gist.github.com/klange/2ef0daf6ee61aeee8add4c9c9e23d192
01:11:00 <bslsk05> gist.github.com: meson.build · GitHub
01:14:00 <heat> eww
01:14:00 <heat> actually, I don't need that do I
01:15:00 <heat> wait... hmm
01:16:00 <heat> yeah I probably do
01:16:00 <klange> This does pretty much exactly what it's supposed to do. Any cleanup would be around getting rid of the stdlib/stdio bits, but I wanted to ensure it wasn't evaluating a constant or something silly.
01:16:00 <heat> yep
01:18:00 <klange> maaaybe replace atof with strtod since I don't actually use 'atof' but I do expect 'strtod' to exist as the compiler uses it.
01:18:00 <klange> so if you get extraneous failures from either of printf or strtod you are extra fucked anyway :)
01:24:00 <mrvn> atof() is horrible. You should replace that anyway regardless of other concerns.
01:52:00 <epony> avoid a2m
01:58:00 <klange> At least make sure the "a" is clean and sanitary first.
02:06:00 <heat> klange, re codecs, that is SUPER awkward
02:06:00 <heat> is there no way those scripts could be idk, shell scripts?
02:06:00 <heat> cuz this forces a cross compile to build two kurokos
02:24:00 <klange> Uh, no, they are huge complicated Kuroko scripts - and I didn't even write them.
02:24:00 <klange> Meson doesn't support "build the thing, then use it to build other things"?
02:26:00 <heat> yes
02:26:00 <heat> it's just awkward
02:46:00 <klange> I guess we _could_ commit the results...
02:47:00 <klange> but they're, like, 3M for dbdata.krk and 1.3M for dbextra_data_8bit.krk
12:17:00 <klange> Can do that little __builtin_floor check in the Makefile: https://gist.github.com/klange/4f712b43273344e85a78c0b4fecd8a2a (adds maybe ~0.02s of time to each make invocation on my desktop)
12:17:00 <bslsk05> gist.github.com: diff.patch · GitHub
13:34:00 <johngammerson> ey hey
13:34:00 <johngammerson> hey
13:36:00 <nikolar> Hello there
13:47:00 <ilovethinking> is it an elegant "hack" to make my grub image in a vm
13:47:00 <ilovethinking> and then run it on my host
13:49:00 <Mutabah> eh, not really elegant or a hack? Seems maybe practical though
14:22:00 <gog> hi
14:23:00 <zid> goggle
14:25:00 <gog> ziddle
14:25:00 <gog> what's crackin
14:25:00 <zid> I take it I was banned from playing factorio for my staunch anti-gog stance
14:26:00 <zid> and pro-tree
14:26:00 <gog> no i just quit playing again
15:44:00 <pitust> ilovethinking: why are you hell-bent on using grub?
15:44:00 <gog> heh
15:44:00 <pitust> lmao
15:48:00 <pitust> i think that answers that question doesn't it
15:48:00 <gog> not really
15:49:00 <pitust> he was banned from the osdev discord before joining here
15:49:00 <gog> heh
15:50:00 <pitust> soo
15:52:00 <gog> do you know why
15:53:00 <pitust> gog: why he was banned? "discord ban evasion"
15:53:00 <gog> ooh
15:54:00 <zid> doesn't surprised me he'd get banned from anywhere with moderation
15:54:00 <gog> i should be working but my boss went home and i already did two tickets today
16:06:00 <gog> i'm doing the opposite of working and looking at ilovethinking's code
17:10:00 <johngammerson> hewwo fwend
17:10:00 <johngammerson> s
18:45:00 * geist yawns
18:45:00 <geist> think i have a cold :(
18:45:00 <geist> also my cat left a dead mouse next to my bed
18:45:00 <geist> though thats actually kinda cute
18:46:00 <mjg> that's like giving you a dead fish in a mafia movie
18:46:00 <mjg> nobody gets this
18:56:00 <ilovethinking> hey, good news: i managed to get grub-mkrescue work on docker
18:56:00 <ilovethinking> bad news, im trying to put OK onto the screen but there's nothing
18:57:00 <ilovethinking> mov dword [0xb8000], 0x2f4b2f4f
18:57:00 <ilovethinking> it just does nothing, what can be the reasons to this?
19:00:00 <gog> geist: ew but aw
19:00:00 <geist> gog: yeah, shes a sweetie when it comes to murdering smaller animals and presenting to me
19:00:00 <geist> but she is a cat, and thus thinks of murder all day
19:00:00 <gog> one of the local cats that we used to let in brought a huge rat and a bird in
19:01:00 <gog> we stopped letting her in after that lol
19:01:00 <ilovethinking> ew gog
19:01:00 <ilovethinking> i thought u were nice
19:01:00 <gog> the rat i found right away, the bird was under my bed for a couple days i think :|
19:12:00 <nikolar> Did you find it by smell
19:14:00 <gog> no i saw her go under the bed with the rat so i looked and also found the bird
19:14:00 <gog> glad i did because i didn't want to find it by smell lmao
19:14:00 <zid> my mother did a good one
19:15:00 <zid> found an injured bird and left it on the window sill
19:15:00 <zid> it was missing when she came back to check on it, shut the window and forgot about it
19:15:00 <zid> found it a few days later rotting on the floor
19:16:00 <gog> oops
19:31:00 <gorgonical> Who allowed the arm people to name two very different registers one letter different: midr_el1 and mpidr_el1
19:32:00 <gorgonical> I've got secondary core bringup saying it's initializing core #4294967295 and while I don't know much I'm pretty sure this SBC doesn't have that many cores
19:32:00 <GeDaMo> Easter egg! :P
19:32:00 <geist> heh. well, yeah
19:33:00 <geist> they like their letter soup for registers
19:33:00 <geist> also if you note: mpidr has some high bits that means something
19:33:00 <geist> so yo uneed ot mask those out to get the raw number
19:33:00 <gorgonical> yeah like cluster naming or something right
19:34:00 <geist> there are 3 or 4 8 bit fields (AFF0, AFF1, etc) and iirc bit 31 or whatot is 'this is part of a SMP system' bit
19:34:00 <gorgonical> yep yep
19:34:00 <geist> or something like that, it's useless now, but you hae to mask it out
19:34:00 <geist> or there's an MT bit i think, saying if this is SMT or not
19:34:00 <gorgonical> "arm64 is better because it doesn't have the x86 legacy" is increasingly untrue
19:34:00 <gorgonical> but it's better
19:34:00 <geist> it may be more logical because it has less legacy, but it's also designed by computer engineers
19:35:00 <geist> so they tend to be less friendly, more 'up your game' to deal with it
19:35:00 <gorgonical> "don't like how the chip works? make your own lmao"
19:36:00 <geist> "as long as it conforms to these 1700 details on this checklist"
19:36:00 <gorgonical> computer engineers are crazy people
19:36:00 <geist> riscv is like dealing with a go-kart in comparison. kinda fun, though as soon as you start really trying to compete you realize you're way behind
19:37:00 <geist> and lots of smart people are having lots ofmeetings to add more layers of complexium that is inevitable
19:37:00 <gorgonical> my uncle in law is a process engineer at ibm and his entire career is predicated on the chemistry of increasingly miniaturizing components
19:41:00 <mjg> > uncle in law
19:41:00 <mjg> lol
19:41:00 <mjg> or is that something people actually say
19:41:00 <gorgonical> i mean he's my partner's uncle so
19:41:00 <gorgonical> lol
19:42:00 <gorgonical> i suppose specifying the relationship is unneeded and just uncle would have been good enough
19:42:00 <mjg> that much i understood
19:42:00 <mjg> i'm saying it sounds funny
19:42:00 <gog> i'm your mother's cousin's houskeeper's brother's former college roommate
19:42:00 <sbalmos> your'... DAMMIT
19:42:00 <mjg> mother in law's
19:42:00 <sbalmos> damn you gog
19:43:00 <gog> :D
19:43:00 <gorgonical> i could never have guessed the flak I'm getting for this
19:43:00 <mjg> what flack
19:43:00 <sbalmos> nobody expects The Spanish Inquisition
19:43:00 <mjg> i'm sayng it is funny, not that you should contriburte to openbsd
19:44:00 <mjg> arthur flak
19:44:00 <gorgonical> that's a deep cut
19:48:00 <geist> yah i always thought 'in law' sounds bad
19:48:00 <geist> for no particular reason, i just dislike saying it too
19:49:00 <gorgonical> i propose an alternative set of words: wuncle/huncle/spuncle and waunt/husbaunt/spaunt depending on what you call your martial partner
19:50:00 <gorgonical> >martial partner
19:50:00 <gorgonical> I'm full of it today huh
19:50:00 <mjg> :]
19:50:00 <mjg> step uncle
19:50:00 <gorgonical> stuncle
19:50:00 <gorgonical> speaking time parsimony
19:51:00 <mjg> ex-lawyer in law
19:51:00 <mjg> i wrote a patch 7 months ago, worked like in a shampoo commercial
19:51:00 <mjg> rebased it today, liek 0 conflicts
19:51:00 <mjg> ... and it crashes
19:51:00 <xvanc> ex-half-sister-in-law, thrice removed
19:51:00 * mjg <-- sad panda
19:51:00 <gorgonical> can we just get back to lojban in terms of linguistic density with kinship terms this way?
19:52:00 <gorgonical> so not "rebase, commit, repeat"?
19:52:00 <mjg> did you know that git has a command literally named 'rerere'?
19:52:00 <gorgonical> what in tarnation
19:52:00 <gorgonical> "Reuse recorded resolution of conflicted merges"
19:52:00 <mjg> https://git-scm.com/docs/git-rerere
19:52:00 <bslsk05> git-scm.com: Git - git-rerere Documentation
19:53:00 <gog> heh wish i knew to tell my boss about this one
19:54:00 <gog> he was in merge hell yesterday (because of me but also him)
19:54:00 <sbalmos> git still doesn't have a git wuewuewue though
19:54:00 <gog> when will they have git wololololo
19:54:00 <mjg> :]
19:54:00 <gog> so you can convert peasants
19:54:00 <mjg> that cuold easily be cvs import
19:54:00 <gorgonical> a tool for converting other cvs systems to git repos
19:54:00 <gog> yes!
19:54:00 <gog> hahaha
19:55:00 <gog> do it for the dank meem
19:55:00 <sbalmos> can I have git lalala which ignores all merge conflicts and just shoves everything up the pipe?
19:55:00 <gorgonical> that's just git push --force
19:55:00 <sbalmos> I know, but lalala sounds better. ignores more.
19:55:00 <mjg> you forgot git add and commit
19:55:00 <gorgonical> git justfuckingdoit
19:55:00 <GeDaMo> https://www.youtube.com/watch?v=tM35QpUt0DY
19:55:00 <bslsk05> 'Don't Push It Don't Force It' by Leon Haywood - Topic (00:05:27)
19:55:00 <mjg> alias ffs=sudo !!
19:55:00 <mjg> protip^^
19:56:00 <gorgonical> an interesting idea would be a git dwim tool that attempts to guess what you want to do based on context, like emacs packages do
19:56:00 <gorgonical> git dwim; !!; !!; !! should result in a succesful commit merge push cycle
19:56:00 <gorgonical> automagically
19:56:00 <gorgonical> it would have the added bonus of being enormously cursed
19:56:00 <mjg> how about the following extension
19:57:00 <mjg> checks how much of a spaghetti your lcal clone is
19:57:00 <mjg> and tells you to get a job at mcdonalds instead of coding
19:57:00 * mjg hacks it up real quick
19:57:00 <gorgonical> "if you like spaghetti so fucking much get a job at olive garden"
19:58:00 <gog> ngl i should be working in food service rather than coding
20:00:00 <sbalmos> git down && boogey
20:06:00 <geist> git on up && git down
20:07:00 <gorgonical> thoughts on whether wednesday should be pizza day lads
20:08:00 <sbalmos> geist: Returned E_OWW!
20:20:00 <mrvn> gorgonical: git can import cvs, svn, hg
20:21:00 <mrvn> probably even rcs
20:21:00 <gog> cvs is just spicy rcs
20:22:00 <mrvn> importing cvs is a real pain though because you have to figure out what makes a version across all the files.
20:22:00 <gog> i never really used it much
20:23:00 <gog> i only know that it's based on rcs which i never used directly :P
20:23:00 <mrvn> every file has a version but you might have "foo.h v1.2" and "foo.c v1.1.3" because they are all versioned separately.
20:23:00 <mrvn> Note: . means a fork
20:24:00 <FireFly> that sounds like pain
20:24:00 <gorgonical> that's really how the versioning works? jesus christ
20:24:00 <gorgonical> that's ridiculous
20:25:00 <gog> i did use svn a bit more and i remember it being annoying
20:30:00 <zid> svn is cvs done right though!
20:30:00 <zid> Meaning it actually supports commits, being the main change
20:33:00 <gorgonical> an actual osdev question: this secondary core bringup has got garbage in the cpu_id field, but I know I'm setting it on the first core. This smells like a cache coherence problem, but it's unclear how I could be sure. I was pretty sure I ironed this problem out before.
20:34:00 <gorgonical> Because the value goes from 0 to 1 on the first core, but the second core reads some garbage value. So it sounds like cache pollution or coherence. Does anyone know if it's possible to force coherence with flushes or similar? E.g. to figure out if my page tables are misconfigured or whatever?
20:34:00 <gorgonical> Before I delve into the tags and manuals and such
20:34:00 <gorgonical> this isram64
20:35:00 <gorgonical> arm64*
20:36:00 <FireFly> is a VCS without commits even a VCS? :p
20:39:00 <gorgonical> oh wait. I just realized this value is 0xffffffff, which makes me think I'm setting this somewhere else
20:40:00 <gorgonical> So someone is infact setting this value elsewhere. But y tho
21:01:00 <mrvn> gorgonical: cores come up without caches and atomic operations do not work without that. So having some reference count for the core-id that each core increments is not going to work.
21:01:00 <mrvn> ARM has a special opcode to reading a core id. you should probably just use that
21:03:00 <mrvn> FireFly: that deepends on what a version is
21:04:00 <geist> mrvn: hmm? not that i know of
21:05:00 <geist> gorgonical: are you using PSCI to boot the secondaries?
21:05:00 <gorgonical> yes
21:05:00 <gorgonical> I have done more investigating and I actually think there's something worse going on
21:06:00 <geist> okay. yeah if you have data structure the secondary is going to read, you'll want to at least clean it from the primary first
21:07:00 <geist> so that when the secondary comes up with the cache off it reads the proper version out of dram directly
21:07:00 <geist> bt if the arg isnt coming through from PSCI that does indeed sound worse
21:07:00 <mrvn> If you want to make it simple bring up all cores before turning on caches or don't read any shared data before bringing up caches on other cores
21:08:00 <mrvn> In the former case you can't use any read-modify-write as far as I know.
21:08:00 <geist> right, that's cutting off your arm and making life a lot worse for less gain
21:11:00 <mrvn> I kind of doing both. I keep the initial page table I use to turn on cache and switch to higher half and they ger reused be each core to bootstrap. But the real work only starts with caches.
21:11:00 <gorgonical> geist: I am issuing dcache clears on the primaries. Well actually the args are coming in from PSCI just fine, and I have a pc-relative struct I store stuff in for the secondary cores that are coming up. The problem is that secondary_data struct contains garbage. I just verified that the page tables on the secondary are right
21:12:00 <gorgonical> I.e. the secondary is looking in the right place, but the right place contains trash
21:12:00 <gorgonical> With my luck it will be more of TF-A doing some shenanigans
21:12:00 <mrvn> Can the cache of the new core contain stale entries?
21:13:00 <gorgonical> It could, I think
21:13:00 <gorgonical> Because of TF-A and uboot's presence it's not possible for me to really know what the core was doing before I psci boot it
21:13:00 <mrvn> isn't there a "drop this cache entry" for this case?
21:14:00 <gorgonical> I'll make sure I am in fact emptying the core's cache when we enter head.S
21:15:00 <gorgonical> I haven't worked on the secondary bootup sequence in a long time so I've kind of forgotten how it works
21:16:00 * mrvn too. But I remember having de-sync problems too
21:16:00 <mrvn> it's tricky to get right
21:18:00 <gorgonical> I am in fact running a flush_dcache_all on the secondary core
21:18:00 <mrvn> and the primary?
21:19:00 <gorgonical> The primary issues an area-based flush
21:19:00 <mrvn> lets hope the secondary doesn't have any dirty cache lines you are flushing out
21:20:00 <gorgonical> But a dirty flush shouldn't cause writeback to these addresses
21:21:00 <gorgonical> At least not on the secondary cores
21:21:00 <gorgonical> The memory that the kernel is executing from is pretty far away from what uboot and tf-a would be operating in
21:23:00 <gorgonical> BRUH
21:23:00 <gorgonical> Wow how has this not been a problem before???
21:23:00 <gorgonical> This is actually *staggering* that this was missed
21:26:00 <gorgonical> for your schadenfreude pleasure: https://pastebin.com/RXP3utab
21:26:00 <bslsk05> pastebin.com: smp.h:struct secondary_data { void* stack; struct task_struct* task; lon - Pastebin.com
21:49:00 <mrvn> did you forget the virt_to_phys?
21:50:00 <mrvn> where do secondary cores put their page table?
21:53:00 <mrvn> gorgonical: confess. what did you forget?
21:54:00 <sbalmos> lest you be placed in the Comfy Chair
21:57:00 <gorgonical> __flush_dcache_area(new_task, sizeof(struct task_struct)); is what I forgot
21:57:00 <gorgonical> I'm flushing the secondary_data but not the fucking task_struct it points to, lol
22:18:00 <tepperson> hello, I am trying to boot a basic do nothing kernel into long mode (booted using grub2), after i enter long mode, i set the segment registers then do call 0x100080 (actually a symbol, but thats what the address is). the cpu then executes code at 0x7e instead
22:21:00 <tepperson> jmp 0x100080 has the same result
22:43:00 <gorgonical> tepperson: are you running on qemu?
22:43:00 <gorgonical> I ask because you can attach a gdb instance to qemu this way and single-step code to see exactly what's happening