klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
SGautam has joined #osdev
<geist> it's one of the reasons i dont like recursive page tables. they get kinda tricky to deal with on SMP as well
<geist> plus they're kinda an x86 only trick, so to me it's at best a neat trick you only get to use on that arch
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
<heat> why don't they work on other archs?
<Mutabah> It only works if every level of the page tables has the same (or compatible) structure
<Mutabah> Kinda works with riscv iirc, you can hack it kinda with ARM...
<heat> yeah riscv should work fine
<heat> does it not work on arm64?
* heat still doesn't understand arm64 paging and blames the manuals
<Mutabah> I think it might?
<Mutabah> well, I beat it into submission
<geist> i dont think it works with arm4
<geist> the inner entries are different in a few ways
<geist> or at least some of the leaf node flags are interpreted differently in inner nodes in ways that i think are Bad
<geist> i remember at some point really walking through the details and deciding it was a no-go
<geist> may work if you dont use some of the more powerful bits
<heat> btw, re printf_tests, geist you should pull fuchsia's printf_tests, they got a lot more stuff than lk's version
<heat> and don't actually print things, which is probably a plus I would guess
<geist> i should yes
<geist> yah i've been slowly going through and converting things to unit test framework which i pulled back from fuchsia
<heat> yeah it looks cute
<heat> it's like budget googletest
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
h4zel has quit [Ping timeout: 248 seconds]
<geist> yeah
<geist> need to add a little app/autoexec that if you include it will run whatever script file you give it
<geist> and then i'll have it set up to have a CQ/CI like thing with qemu
Likorn has joined #osdev
sonny has quit [Quit: Ping timeout (120 seconds)]
sonny has joined #osdev
<heat> i've been thinking about just piping a file full of inputs into qemu for CI tests
corecode has quit [Ping timeout: 240 seconds]
<geist> yah that's really the next strategy
<heat> it seems more possible in my situation since it's a full posix-ish OS
<geist> yah
<heat> how would you pass the script anyway? fwcfg?
<geist> oh just INCBIN it
<geist> or something like that
<geist> ie, #include effectively
<klys> incbin is a gas directive?
<geist> yah i have some wrapper #define that pulls it in and makes a symbol out of it
<klys> well fuchsia is not a modular kernel, correct? so you have some other stuff that comes after it...
<heat> we're talking about lk, not fuchsia
<klys> oh
<heat> fuchsia already runs tests as part of their CI
<geist> yah
<geist> and there's a user space test in the fuchsia CI that just runs the kernel unit tests
<geist> 'k' commands in fuchsia are really just the LK command line, hidden. basically it feeds commands into a LK shell
<klys> as I recall there was a more modular approach to lk out there somewhere just not your doing
<geist> there's a fun command line option `kernel.shell=1` that turns the old LK command line back on again
<geist> oh i dunno!
<geist> but lots of folks use LK in places i dont know about
<klys> well it's hearsay then
<heat> just found a project that ran dart on top of lk
<heat> heh
<geist> which dart?
<heat> google dart
* geist nods
<heat> dartino
<geist> yep, i worked on that. actually worked pretty well
<geist> also folks have used it as a basis to run lua on top of and whatnot. works pretty well for that
<geist> also i think i've seen folks run arduino on top of it. basically spawn a thread that acts like the arduino framework
<geist> so you can still run your single threaded thing, but actually can be preempted by other stuff
<klys> dartuino?
<heat> hehehehe
<heat> wait actually that doesn't work
* heat un-hehehehe's
sonny has quit [Ping timeout: 252 seconds]
<heat> ok, this makes no sense: https://godbolt.org/z/ccbqf1K1W
<bslsk05> ​godbolt.org: Compiler Explorer
<heat> is there something painfully obvious I'm missing or is clang noexcept just broken?
<klys> -O2 ? try -O0
<geist> perhaps both. basically clang is hyper aggressive about it
<geist> we have this whole workaround in the kernel for it. the new -fcheck-new that gcc supports seems to do what yo uwant
<geist> but clang doesn't seem to support it
<heat> no-one compiles with -O0
<heat> unless if you're building something with clang in debug mode, because it does *not* debug nicely with -O1+, and -Og is not a thing there
<bslsk05> ​godbolt.org: Compiler Explorer
<heat> geist, yeah I saw your issue and got curious
<heat> this *should* work
<geist> so what we do in fuchsia is forbid throw and std::nothrow versions
<geist> but *any other* overridden new it'll assume it can be null
<bslsk05> ​godbolt.org: Compiler Explorer
<geist> so we have the AllocChecker versions
<klys> yeah this syntax is new to me: new(param) type
<geist> you can extend operator new with whatever you want, the compiler will jsut try to match it up like all other overridden function args
<geist> heat: the key is if you call the non nothrow versions both compilers will assume it can never be null, even with -fno-exceptions
<bslsk05> ​godbolt.org: Compiler Explorer
<heat> ye, i know that
<geist> but with -fcheck-new it'll at least undo that behavior in gcc
<bslsk05> ​godbolt.org: Compiler Explorer
<heat> like "theoretically" nothrow new() should check for null since it's allowed to return null
<geist> the std::nothrow version of course will always behave this way, i think according to spec
<heat> i'm looking through the spec for a better reference
<geist> i think i found a mention of it in the cppreference the other day, but dont remember where
<heat> clang folks told me it's not supported probably because no one ever added it
<geist> but i think it's more lie the throw version cannot return null, but all other variants and overrides may
<geist> what's interesting is it understands the switch and doesn't complain about it
<bslsk05> ​eel.is: [namespace.posix]
<bslsk05> ​eel.is: [expr.new]
<Ali_A> geist I am trying to understand, the link u post to compiler explorer, I haven't touched C++ in ages, but I don't understand, the point the function declaration u done ? (like what is it being used fo? shouldn't usually, you provide an overloaded definition?)  + I never seen this syntax of new (new(1) int) which I assume, is the same as new
<Ali_A> int(1);
<heat> this looks pretty clear to me
<heat> the (1) is an argument passed to operator new
<heat> new(1) int(0) = operator new(sizeof(int), 1)
<Ali_A> what is the point of `int(0)` there?
<heat> construct the int with 0, but that's just me being overly explicit here
<heat> the default constructor will already construct it with 0 afaik
<heat> actually, it won't, my bad
<Ali_A> didn't know that new had default `initialisation` I thought, that doesn't exist ?
<heat> of course, the POD constructors don't do anything because why would they am I right
<heat> new will call the default constructor
<heat> it just so happens that the POD types' default constructors don't do anything because screw memory safety
<Ali_A> yes, make sense, because this is inherited from C as far as I know (u don't do initialisation unless explicitly told )
<heat> it does do initialisation even if you don't type it out
<Ali_A> but I still don't understand the point of the overload declaration on top?
<Ali_A> or would it be linked later or something?
<heat> the compiler will eliminate the if(!p) because standard non-noexcept operator news can't return nullptr
<heat> they just throw
<geist> oh the reason i did that was to just create a new variant of operator new
<geist> i just picked int, the number is irrelevant
<geist> just wanted to overload it with something custom
<geist> to point out when it calls an overloaded, non-standard, nothrow new it assumes it can return null
<heat> geist, found out what the problem was
<geist> oh yeah?
<heat> clang sees through the new() and doesn't even call it, ever
<heat> that's why if(!p) gets optimised out
<geist> well sure but that's becase it's optimized out the if, and thus decides it doesn't need to call it in the first place
<geist> gcc does the same thing, based on it knowing that the result is a given (null)
<bslsk05> ​godbolt.org: Compiler Explorer
<bslsk05> ​godbolt.org: Compiler Explorer
<geist> this all tracks. the nothrow version can return null, thus it checks
<geist> the throw version cannot according to spec, thus they remove the test
<geist> and gcc honors the switch: https://godbolt.org/z/6PrbfYK6K
<bslsk05> ​godbolt.org: Compiler Explorer
<heat> yup
<heat> but because the std::nothrow_t variant is standard C++, they assume standard C++ semantics
<heat> and those probably let clang eliminate the new inside main
<heat> even nothrow new
<geist> most likely it's any function where you allocate and then dont do anything with it
<geist> its like 'oh this is leaked, lets not even bother calling it'
<heat> oh it is, yes
<heat> interesting
<bslsk05> ​godbolt.org: Compiler Explorer
<geist> yup
<geist> side note i saw some -f switch the other day in gcc docs that tries to catch leaks like this
<heat> the static analyzer?
jack_rabbit has joined #osdev
<geist> -Wmismatched-new-delete it seems, but it doesn't catch this case
knusbaum has quit [Ping timeout: 276 seconds]
<geist> oh that's already on
<geist> that's just new[]/delete or new/delete[]
<heat> -Wmismatched-new-delete catches new/free() too
<heat> or malloc()/delete
<geist> -Wmismatched-dealloc
<geist> i think i saw it because of the MALLOC attribute docs or whatnot
<geist> you can mark a function as returning something that was malloced
<geist> so the compiler knows for these sort of warnings
<geist> anyway some fun warnings and switches in https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html
<bslsk05> ​gcc.gnu.org: C++ Dialect Options (Using the GNU Compiler Collection (GCC))
<bslsk05> ​godbolt.org: Compiler Explorer
<heat> the plot thickens
<heat> D:
<geist> huh!
<geist> even if you set the language to C (via -x c or via changing the language)
<geist> that desn't seem right
<geist> oh but sam thing: it's an allocated thing that doesn't get used
<heat> https://godbolt.org/z/jjhbvfo3b <-- in this case gcc can also detect the useless malloc()
<bslsk05> ​godbolt.org: Compiler Explorer
<heat> compilers are horrific black magic screw this
<geist> heres a fun one: https://godbolt.org/z/obzjjrMc3
<bslsk05> ​godbolt.org: Compiler Explorer
<geist> tells you that the compilers have different assumptions about the alignment of the values
<heat> gcc assumes 8 byte alignment apparently
<heat> which is definitely correct
<geist> but yeah this sort of stuff is exactly why supporting muyltiple compilers at different versions is not as trivial as folks think
<geist> especially for system software/kernels/etc that tend to push the boundaries a bit harder than usual app code
<heat> tbf this is all horrible code
<heat> gcc 4.6.4 knows the alignment of malloc'd memory but doesn't delete the malloc call
<heat> 4.7.1 deletes everything
<heat> ok what
<heat> max_align_t has an alignment of 16 bytes
<heat> but gcc doesn't assume malloc won't return things 16-byte aligned
<heat> cancel compilers
JanC has quit [Remote host closed the connection]
JanC has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
terrorjack has quit [Quit: The Lounge - https://thelounge.chat]
terrorjack has joined #osdev
nyah has quit [Ping timeout: 276 seconds]
srjek has joined #osdev
gog has quit [Ping timeout: 276 seconds]
Ali_A has quit [Quit: Connection closed]
heat has quit [Ping timeout: 260 seconds]
Mutabah has quit [Ping timeout: 276 seconds]
srjek has quit [Ping timeout: 260 seconds]
Mutabah has joined #osdev
<kazinsal> the latest intel C compiler goes ahead and does something baffling: it optimizes out the malloc etc, but prefixes the whole thing by setting the FZ and DAZ bits in the MXCSR register
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
xenos1984 has quit [Quit: Leaving.]
SGautam has quit [Quit: Connection closed for inactivity]
<kazinsal> heh. Microsoft open sourced 3D Movie Maker
<kazinsal> apparently purely on the grounds of "foone asked really nicely"
<mxshift> Foone has been asking for years
<geist> yah no one listens to Foone
<kazinsal> apparently they open sourced GW-BASIC a while ago and I never noticed
<moon-child> ooh cool
<moon-child> I have absolutely no personal investment or interest in this, but still: cool
<klange> I think the instigating factor here was that Foone got the copyright holders for the 3D engine on board with open sourcing _that_, so Microsoft followed through with the rest of 3D Movie Maker.
<geist> kazinsal: oh huh!
<geist> i might be interested in that, i spent many hours in my youth fiddling with gwbasic
<mxshift> Knowing Foone a little bit, Scott Hanselmen definitely brought a lot of industry connections to make it all possible
<geist> (oh huh, Foone is a real person. i was thinking it was a pun)
<mxshift> Yes, real person. Have met them in person.
<geist> ah probably nice person
<klange> I have only "met" them on IRC, but yes.
Vercas has quit [Quit: Ping timeout (120 seconds)]
gildasio has quit [Ping timeout: 240 seconds]
gxt has quit [Ping timeout: 240 seconds]
zaquest has joined #osdev
dminuoso has joined #osdev
<dminuoso> Hiya. Im looking for some input with regard to usb devices.
<dminuoso> It's not exactly OS work, but Im hoping for some insights into working with HID compliant devices
<dminuoso> Would just using threads myself, and a reader thread that continouosly calls hid_read_timeout be a sufficient alternative?
nomagno has quit [Quit: Bridge terminating on SIGTERM]
hgoel[m] has quit [Quit: Bridge terminating on SIGTERM]
Irvise_ has quit [Quit: Bridge terminating on SIGTERM]
chibill has quit [Quit: Bridge terminating on SIGTERM]
junon has quit [Quit: Bridge terminating on SIGTERM]
haliucinas has quit [Ping timeout: 272 seconds]
Vercas has joined #osdev
gildasio has joined #osdev
gxt has joined #osdev
Irvise_ has joined #osdev
chibill has joined #osdev
junon has joined #osdev
hgoel[m] has joined #osdev
bauen1 has quit [Ping timeout: 248 seconds]
corecode has joined #osdev
bauen1 has joined #osdev
<Griwes> Ahhh, another successful late evening of staring at binary trees and figuring out where the bug is
<Griwes> Looks like I killed all the instabilities now
<kazinsal> reminds me, I need to finish my 256-way radix tree route cache...
<Griwes> Just need to finish making my primitive "first stage" elf loader actually respect the correct symbol order and I think I'll be done with this "small" change/refactor
<Griwes> And then I'll actually have two *reasonable* things to choose between as the next thing to work on, huh
<kazinsal> actually yeah I need to finish my kernel core rewrite. only been saying I need to do it for like, six months now
<Griwes> I'll need to make my dumb scheduler *slightly* less dumb by making it actually use more than one core, that's one path
<kazinsal> step 1 is complete (solidly get into 64-bit mode). step 2 is going to really just be an annoyance more than anything else (magic paging bullshit)
<Griwes> And I'll need to actually start figuring out a DSL and APIs for the IPC framework for this whole project
<Griwes> That's second path
<Griwes> I think I know the order now that I said it
<kazinsal> following that it's "rewrite internal memory management APIs for 64-bit systems" and then "start bolting shit on"
<Griwes> Because one is fairly obviously a conceptually smaller task than the other
<Griwes> Anyway feels good to actually accomplish a thing, especially with work work being a bit of a slog recently, where I'm refactoring a non trivial thing to match a spec, so it's been weeks since my branch of the thing was in a working state lol (I need to rework the whole non trivial thing, and that's a big chunk of work...)
<kazinsal> yeah, I feel that. I had about six weeks of banging out all the remaining work I had before moving to a new team and it felt like the longest days I've had in at least five years
<kazinsal> now I'm just kinda sitting around waiting for new projects to show up. probably ought to write some code during those hours...
Burgundy has joined #osdev
tomaw has quit [Quit: Quitting]
tomaw has joined #osdev
pretty_dumm_guy has joined #osdev
gog has joined #osdev
bliminse has quit [Ping timeout: 240 seconds]
bliminse has joined #osdev
GeDaMo has joined #osdev
brynet has quit [Ping timeout: 240 seconds]
brynet has joined #osdev
brynet has quit [Ping timeout: 260 seconds]
brynet has joined #osdev
kingoffrance has quit [Remote host closed the connection]
nyah has joined #osdev
Dyskos has joined #osdev
dennis95 has joined #osdev
elastic_dog has quit [Killed (osmium.libera.chat (Nickname regained by services))]
elastic_dog has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
srjek has joined #osdev
xenos1984 has joined #osdev
Vercas has quit [Ping timeout: 240 seconds]
Likorn has joined #osdev
xenos1984 has quit [Ping timeout: 260 seconds]
heat has joined #osdev
vdamewood has joined #osdev
muffin has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
<heat> kazinsal, how does a radix tree work as a fib?
<heat> my FIB is still just a plain array (works fine with the few routes it has)
<heat> I guess you could fill every entry that doesn't have a route with a default gateway?
<heat> and then what happens to routes that use a different interface? i.e two default routes
Dreg has joined #osdev
not_not has quit [Quit: Lost terminal]
Dreg has quit [Read error: Connection reset by peer]
Dreg has joined #osdev
dennis95 has quit [Quit: Leaving]
Likorn has joined #osdev
xenos1984 has joined #osdev
dude12312414 has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
pretty_dumm_guy has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
jjuran has quit [Remote host closed the connection]
jjuran has joined #osdev
bauen1 has quit [Ping timeout: 248 seconds]
Vercas has joined #osdev
srjek has quit [Ping timeout: 260 seconds]
muffin has left #osdev [WeeChat 3.5]
srjek has joined #osdev
bauen1 has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
GeDaMo has quit [Remote host closed the connection]
<bslsk05> ​godbolt.org: Compiler Explorer
<heat> any c++ template wizards know what's wrong?
<heat> I basically want to call c<AF_INET> when i'm AF_INET, c<AF_INET6> when I'm AF_INET6. but I only know this at runtime so I need to wrap it in this nice utility function
<heat> this would easily be done in a macro but I want to see if I can template it into submission
<Griwes> you can't pass function templates around
<Griwes> I'll give you an alternative though, one sec
<Griwes> hmm, wait, it's slightly more complex than I thought it was
<Griwes> you can't pass function templates around, and you can't currently easily pass overload sets around either
<Griwes> (I tried to make the latter happen but apparently it wasn't sufficiently motivated for the core language evolution group -.-)
<Griwes> heat, how much do you hate this? https://godbolt.org/z/eqabaT4o7
<bslsk05> ​godbolt.org: Compiler Explorer
<heat> a lot
<Griwes> I think this is the best you can do in current C++ without macros
<heat> is template <typename Type> void f(int) a type or a function?
<Griwes> neither
<Griwes> it's a function template
<heat> I thought of https://godbolt.org/z/rY4bsvMsf but it doesn't work
<bslsk05> ​godbolt.org: Compiler Explorer
<Griwes> and function templates are a non-first-class citizen
<gog> heat: yu want explicit template specialization
<Griwes> there is nothing to explicitly specialize in that snippet in any meaningful to the problem form, I think
<gog> but i'm not sure you can do it on non-member functions yeah
<gog> or a function without a template parameter
<gog> idk
<Griwes> the usual technique to be able to "pass" a function template around is to wrap it in a struct like I've done
<Griwes> or with the template head on the struct instead of on the function
<Griwes> because both types and type templates *are* first-class (at the template level), so you can pass them as template arguments
<heat> https://godbolt.org/z/nn5cGqd5f c++ standard commitee defeated by a macro-y boi
<bslsk05> ​godbolt.org: Compiler Explorer
<heat> with NON-STANDARD EXTENSIONS
<heat> the boogeyman of commitee people
fwg has quit [Quit: .oO( zzZzZzz ...]
<Griwes> making that a statement expression seems... unnecessary lol
<heat> well I want the return type if it has one
<heat> s/return type/return value/
<Griwes> just remove the braces and the semicolon?
<heat> oh right that works haha
<Griwes> lol
<heat> Griwes, weird question but how is it legal for a compiler to eliminate malloc/new calls?
<dminuoso> Why would it not be legal?
<heat> it has side effects
<bslsk05> ​godbolt.org: Compiler Explorer
<dminuoso> heat: What kind of side effects?
<heat> memory allocation
<dminuoso> Okay, and an executed instruction has heat dissipation as a side effect
<dminuoso> your point being?
<dminuoso> Side effects are a relative thing
<dminuoso> They depend on what you consider a side effect. The real question is, is memory allocation a behavior according to the abstract machine specified by the language standard.
<dminuoso> And I guarantee you its not
<mrvn> Griwes: why not a lambda?
<dminuoso> We can always make the case that any code has side effects, simply because code gets executed on real world machines, and their execution alters the world.
<dminuoso> Whether we can derive useful information from this is another topic
<mrvn> dminuoso: if your real machine does not behave like the C++ machine then that is your problem.
<dminuoso> Oh yes, that's a direct quote from ISO/IEC 14882:2020(E) `4.1.2 Abstract machine` right?
<dminuoso> I think I read that there.
<Griwes> mrvn, because it's less handy to define outside of the call expression
<bslsk05> ​eel.is: [expr.new]
<jimbzy> Howdy
<Griwes> it's an explicit provision to allow for heap elision optimizations
<heat> ahh okay thanks
<Griwes> note that this is *specifically* for new *expressions*
<mrvn> so where is the storage provided then?
<heat> stack for instance
<mrvn> and then removed because nothing uses it?
<mrvn> I don't think this should be legal. The memory is not deleted
Brnocrist has quit [Ping timeout: 276 seconds]
<mrvn> There should be a: 13.1 the pointer value produced by e1 is an operand to an evaluated delete-expression
Brnocrist has joined #osdev
bauen1 has quit [Quit: leaving]
<Griwes> mrvn: but that would be the wrong place to do things to a delete expression ;)
<bslsk05> ​eel.is: [expr.delete]
<Griwes> (specifically the first sentence of 7.1 and the entirety of 7.3)
Dyskos has quit [Quit: Leaving]
bauen1 has joined #osdev
srjek has quit [Ping timeout: 240 seconds]
Ram-Z_ has joined #osdev
Ram-Z has quit [Ping timeout: 260 seconds]
Bonstra has quit [Quit: Pouf c'est tout !]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Likorn has quit [Quit: WeeChat 3.4.1]
simpl_e has quit [Remote host closed the connection]
simpl_e has joined #osdev
Likorn has joined #osdev
Bonstra has joined #osdev
rustyy has quit [Remote host closed the connection]
rustyy has joined #osdev
janemba has joined #osdev
Burgundy has quit [Ping timeout: 248 seconds]