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=22&m=5&d=4
00:07:00 <geist> it's one of the reasons i dont like recursive page tables. they get kinda tricky to deal with on SMP as well
00:07:00 <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
00:08:00 <heat> why don't they work on other archs?
00:12:00 <Mutabah> It only works if every level of the page tables has the same (or compatible) structure
00:13:00 <Mutabah> Kinda works with riscv iirc, you can hack it kinda with ARM...
00:14:00 <heat> yeah riscv should work fine
00:14:00 <heat> does it not work on arm64?
00:15:00 * heat still doesn't understand arm64 paging and blames the manuals
00:15:00 <Mutabah> I think it might?
00:15:00 <Mutabah> well, I beat it into submission
00:18:00 <geist> i dont think it works with arm4
00:18:00 <geist> the inner entries are different in a few ways
00:19:00 <geist> or at least some of the leaf node flags are interpreted differently in inner nodes in ways that i think are Bad
00:19:00 <geist> i remember at some point really walking through the details and deciding it was a no-go
00:20:00 <geist> may work if you dont use some of the more powerful bits
00:20:00 <heat> btw, re printf_tests, geist you should pull fuchsia's printf_tests, they got a lot more stuff than lk's version
00:20:00 <heat> and don't actually print things, which is probably a plus I would guess
00:20:00 <geist> i should yes
00:20:00 <geist> yah i've been slowly going through and converting things to unit test framework which i pulled back from fuchsia
00:21:00 <heat> yeah it looks cute
00:21:00 <heat> it's like budget googletest
00:29:00 <geist> yeah
00:29:00 <geist> need to add a little app/autoexec that if you include it will run whatever script file you give it
00:30:00 <geist> and then i'll have it set up to have a CQ/CI like thing with qemu
00:34:00 <heat> i've been thinking about just piping a file full of inputs into qemu for CI tests
00:35:00 <geist> yah that's really the next strategy
00:35:00 <heat> it seems more possible in my situation since it's a full posix-ish OS
00:35:00 <geist> yah
00:35:00 <heat> how would you pass the script anyway? fwcfg?
00:35:00 <geist> oh just INCBIN it
00:36:00 <geist> or something like that
00:36:00 <geist> ie, #include effectively
00:36:00 <klys> incbin is a gas directive?
00:37:00 <geist> yah i have some wrapper #define that pulls it in and makes a symbol out of it
00:39:00 <klys> well fuchsia is not a modular kernel, correct? so you have some other stuff that comes after it...
00:39:00 <heat> we're talking about lk, not fuchsia
00:40:00 <klys> oh
00:40:00 <heat> fuchsia already runs tests as part of their CI
00:41:00 <geist> yah
00:41:00 <geist> and there's a user space test in the fuchsia CI that just runs the kernel unit tests
00:42:00 <geist> 'k' commands in fuchsia are really just the LK command line, hidden. basically it feeds commands into a LK shell
00:42:00 <klys> as I recall there was a more modular approach to lk out there somewhere just not your doing
00:42:00 <geist> there's a fun command line option `kernel.shell=1` that turns the old LK command line back on again
00:42:00 <geist> oh i dunno!
00:42:00 <geist> but lots of folks use LK in places i dont know about
00:43:00 <klys> well it's hearsay then
00:44:00 <heat> just found a project that ran dart on top of lk
00:44:00 <heat> heh
00:45:00 <geist> which dart?
00:45:00 <heat> google dart
00:45:00 * geist nods
00:45:00 <heat> dartino
00:46:00 <geist> yep, i worked on that. actually worked pretty well
00:46:00 <geist> also folks have used it as a basis to run lua on top of and whatnot. works pretty well for that
00:46:00 <geist> also i think i've seen folks run arduino on top of it. basically spawn a thread that acts like the arduino framework
00:46:00 <geist> so you can still run your single threaded thing, but actually can be preempted by other stuff
00:47:00 <klys> dartuino?
00:47:00 <heat> hehehehe
00:47:00 <heat> wait actually that doesn't work
00:47:00 * heat un-hehehehe's
00:48:00 <heat> ok, this makes no sense: https://godbolt.org/z/ccbqf1K1W
00:48:00 <bslsk05> godbolt.org: Compiler Explorer
00:48:00 <heat> is there something painfully obvious I'm missing or is clang noexcept just broken?
00:49:00 <klys> -O2 ? try -O0
00:49:00 <geist> perhaps both. basically clang is hyper aggressive about it
00:49:00 <geist> we have this whole workaround in the kernel for it. the new -fcheck-new that gcc supports seems to do what yo uwant
00:49:00 <geist> but clang doesn't seem to support it
00:49:00 <heat> no-one compiles with -O0
00:50:00 <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
00:50:00 <geist> https://godbolt.org/z/GYoEscG9E
00:50:00 <bslsk05> godbolt.org: Compiler Explorer
00:50:00 <heat> geist, yeah I saw your issue and got curious
00:50:00 <heat> this *should* work
00:51:00 <geist> so what we do in fuchsia is forbid throw and std::nothrow versions
00:51:00 <geist> but *any other* overridden new it'll assume it can be null
00:52:00 <geist> ie, https://godbolt.org/z/sEozzseav
00:52:00 <bslsk05> godbolt.org: Compiler Explorer
00:52:00 <geist> so we have the AllocChecker versions
00:53:00 <klys> yeah this syntax is new to me: new(param) type
00:53:00 <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
00:55:00 <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
00:55:00 <geist> https://godbolt.org/z/bc83fhjW1
00:55:00 <bslsk05> godbolt.org: Compiler Explorer
00:56:00 <heat> ye, i know that
00:56:00 <geist> but with -fcheck-new it'll at least undo that behavior in gcc
00:56:00 <geist> https://godbolt.org/z/1jxGa7Wxs
00:56:00 <bslsk05> godbolt.org: Compiler Explorer
00:56:00 <heat> like "theoretically" nothrow new() should check for null since it's allowed to return null
00:56:00 <geist> the std::nothrow version of course will always behave this way, i think according to spec
00:56:00 <heat> i'm looking through the spec for a better reference
00:56:00 <geist> i think i found a mention of it in the cppreference the other day, but dont remember where
00:56:00 <heat> clang folks told me it's not supported probably because no one ever added it
00:57:00 <geist> but i think it's more lie the throw version cannot return null, but all other variants and overrides may
00:57:00 <geist> what's interesting is it understands the switch and doesn't complain about it
00:58:00 <heat> TIL https://eel.is/c++draft/namespace.posix
00:58:00 <bslsk05> eel.is: [namespace.posix]
00:59:00 <heat> https://eel.is/c++draft/expr.new#21
00:59:00 <bslsk05> eel.is: [expr.new]
00:59:00 <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
00:59:00 <Ali_A> int(1);
00:59:00 <heat> this looks pretty clear to me
01:00:00 <heat> the (1) is an argument passed to operator new
01:00:00 <heat> new(1) int(0) = operator new(sizeof(int), 1)
01:01:00 <Ali_A> what is the point of `int(0)` there?
01:01:00 <heat> construct the int with 0, but that's just me being overly explicit here
01:01:00 <heat> the default constructor will already construct it with 0 afaik
01:02:00 <heat> actually, it won't, my bad
01:02:00 <Ali_A> didn't know that new had default `initialisation` I thought, that doesn't exist ?
01:03:00 <heat> of course, the POD constructors don't do anything because why would they am I right
01:03:00 <heat> new will call the default constructor
01:03:00 <heat> it just so happens that the POD types' default constructors don't do anything because screw memory safety
01:03:00 <Ali_A> yes, make sense, because this is inherited from C as far as I know (u don't do initialisation unless explicitly told )
01:04:00 <heat> it does do initialisation even if you don't type it out
01:05:00 <Ali_A> but I still don't understand the point of the overload declaration on top?
01:05:00 <Ali_A> or would it be linked later or something?
01:05:00 <heat> the compiler will eliminate the if(!p) because standard non-noexcept operator news can't return nullptr
01:05:00 <heat> they just throw
01:12:00 <geist> oh the reason i did that was to just create a new variant of operator new
01:12:00 <geist> i just picked int, the number is irrelevant
01:12:00 <geist> just wanted to overload it with something custom
01:12:00 <geist> to point out when it calls an overloaded, non-standard, nothrow new it assumes it can return null
01:16:00 <heat> geist, found out what the problem was
01:17:00 <geist> oh yeah?
01:17:00 <heat> clang sees through the new() and doesn't even call it, ever
01:17:00 <heat> that's why if(!p) gets optimised out
01:18:00 <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
01:18:00 <geist> gcc does the same thing, based on it knowing that the result is a given (null)
01:18:00 <heat> https://godbolt.org/z/nofe5KWK1
01:18:00 <bslsk05> godbolt.org: Compiler Explorer
01:19:00 <geist> right. https://godbolt.org/z/qa7oq4hez
01:19:00 <bslsk05> godbolt.org: Compiler Explorer
01:19:00 <geist> this all tracks. the nothrow version can return null, thus it checks
01:19:00 <geist> the throw version cannot according to spec, thus they remove the test
01:20:00 <geist> and gcc honors the switch: https://godbolt.org/z/6PrbfYK6K
01:20:00 <bslsk05> godbolt.org: Compiler Explorer
01:20:00 <heat> yup
01:20:00 <heat> but because the std::nothrow_t variant is standard C++, they assume standard C++ semantics
01:20:00 <heat> and those probably let clang eliminate the new inside main
01:21:00 <heat> even nothrow new
01:21:00 <geist> most likely it's any function where you allocate and then dont do anything with it
01:21:00 <geist> its like 'oh this is leaked, lets not even bother calling it'
01:21:00 <heat> oh it is, yes
01:21:00 <heat> interesting
01:21:00 <heat> https://godbolt.org/z/zjznxao78
01:21:00 <bslsk05> godbolt.org: Compiler Explorer
01:22:00 <geist> yup
01:22:00 <geist> side note i saw some -f switch the other day in gcc docs that tries to catch leaks like this
01:23:00 <heat> the static analyzer?
01:24:00 <geist> -Wmismatched-new-delete it seems, but it doesn't catch this case
01:24:00 <geist> oh that's already on
01:25:00 <geist> that's just new[]/delete or new/delete[]
01:25:00 <heat> -Wmismatched-new-delete catches new/free() too
01:25:00 <heat> or malloc()/delete
01:25:00 <geist> -Wmismatched-dealloc
01:25:00 <geist> i think i saw it because of the MALLOC attribute docs or whatnot
01:26:00 <geist> you can mark a function as returning something that was malloced
01:26:00 <geist> so the compiler knows for these sort of warnings
01:28:00 <geist> anyway some fun warnings and switches in https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html
01:28:00 <bslsk05> gcc.gnu.org: C++ Dialect Options (Using the GNU Compiler Collection (GCC))
01:29:00 <heat> https://godbolt.org/z/G5hxdx1P6
01:29:00 <bslsk05> godbolt.org: Compiler Explorer
01:29:00 <heat> the plot thickens
01:29:00 <heat> D:
01:31:00 <geist> huh!
01:32:00 <geist> even if you set the language to C (via -x c or via changing the language)
01:32:00 <geist> that desn't seem right
01:32:00 <geist> oh but sam thing: it's an allocated thing that doesn't get used
01:34:00 <heat> https://godbolt.org/z/jjhbvfo3b <-- in this case gcc can also detect the useless malloc()
01:34:00 <bslsk05> godbolt.org: Compiler Explorer
01:34:00 <heat> compilers are horrific black magic screw this
01:35:00 <geist> heres a fun one: https://godbolt.org/z/obzjjrMc3
01:35:00 <bslsk05> godbolt.org: Compiler Explorer
01:35:00 <geist> tells you that the compilers have different assumptions about the alignment of the values
01:37:00 <heat> gcc assumes 8 byte alignment apparently
01:37:00 <heat> which is definitely correct
01:38:00 <geist> but yeah this sort of stuff is exactly why supporting muyltiple compilers at different versions is not as trivial as folks think
01:38:00 <geist> especially for system software/kernels/etc that tend to push the boundaries a bit harder than usual app code
01:38:00 <heat> tbf this is all horrible code
01:40:00 <heat> gcc 4.6.4 knows the alignment of malloc'd memory but doesn't delete the malloc call
01:40:00 <heat> 4.7.1 deletes everything
01:42:00 <heat> ok what
01:42:00 <heat> max_align_t has an alignment of 16 bytes
01:43:00 <heat> but gcc doesn't assume malloc won't return things 16-byte aligned
01:44:00 <heat> cancel compilers
04:23:00 <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
05:14:00 <kazinsal> heh. Microsoft open sourced 3D Movie Maker
05:15:00 <kazinsal> apparently purely on the grounds of "foone asked really nicely"
05:30:00 <mxshift> Foone has been asking for years
05:30:00 <geist> yah no one listens to Foone
05:30:00 <kazinsal> apparently they open sourced GW-BASIC a while ago and I never noticed
05:47:00 <moon-child> ooh cool
05:47:00 <moon-child> I have absolutely no personal investment or interest in this, but still: cool
05:48:00 <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.
05:52:00 <geist> kazinsal: oh huh!
05:52:00 <geist> i might be interested in that, i spent many hours in my youth fiddling with gwbasic
05:53:00 <mxshift> Knowing Foone a little bit, Scott Hanselmen definitely brought a lot of industry connections to make it all possible
05:53:00 <geist> (oh huh, Foone is a real person. i was thinking it was a pun)
05:54:00 <mxshift> Yes, real person. Have met them in person.
05:55:00 <geist> ah probably nice person
06:12:00 <klange> I have only "met" them on IRC, but yes.
07:05:00 <dminuoso> Hiya. Im looking for some input with regard to usb devices.
07:05:00 <dminuoso> It's not exactly OS work, but Im hoping for some insights into working with HID compliant devices
07:11:00 <dminuoso> Would just using threads myself, and a reader thread that continouosly calls hid_read_timeout be a sufficient alternative?
09:05:00 <Griwes> Ahhh, another successful late evening of staring at binary trees and figuring out where the bug is
09:05:00 <Griwes> Looks like I killed all the instabilities now
09:06:00 <kazinsal> reminds me, I need to finish my 256-way radix tree route cache...
09:07:00 <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
09:08:00 <Griwes> And then I'll actually have two *reasonable* things to choose between as the next thing to work on, huh
09:08:00 <kazinsal> actually yeah I need to finish my kernel core rewrite. only been saying I need to do it for like, six months now
09:09:00 <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
09:09:00 <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)
09:09:00 <Griwes> And I'll need to actually start figuring out a DSL and APIs for the IPC framework for this whole project
09:09:00 <Griwes> That's second path
09:10:00 <Griwes> I think I know the order now that I said it
09:10:00 <kazinsal> following that it's "rewrite internal memory management APIs for 64-bit systems" and then "start bolting shit on"
09:10:00 <Griwes> Because one is fairly obviously a conceptually smaller task than the other
09:13:00 <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...)
09:14:00 <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
09:14:00 <kazinsal> now I'm just kinda sitting around waiting for new projects to show up. probably ought to write some code during those hours...
15:44:00 <heat> kazinsal, how does a radix tree work as a fib?
15:44:00 <heat> my FIB is still just a plain array (works fine with the few routes it has)
15:45:00 <heat> I guess you could fill every entry that doesn't have a route with a default gateway?
15:47:00 <heat> and then what happens to routes that use a different interface? i.e two default routes
20:20:00 <heat> https://godbolt.org/z/Y3rM9qc5s
20:20:00 <bslsk05> godbolt.org: Compiler Explorer
20:20:00 <heat> any c++ template wizards know what's wrong?
20:21:00 <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
20:22:00 <heat> this would easily be done in a macro but I want to see if I can template it into submission
20:22:00 <Griwes> you can't pass function templates around
20:23:00 <Griwes> I'll give you an alternative though, one sec
20:23:00 <Griwes> hmm, wait, it's slightly more complex than I thought it was
20:24:00 <Griwes> you can't pass function templates around, and you can't currently easily pass overload sets around either
20:24:00 <Griwes> (I tried to make the latter happen but apparently it wasn't sufficiently motivated for the core language evolution group -.-)
20:27:00 <Griwes> heat, how much do you hate this? https://godbolt.org/z/eqabaT4o7
20:27:00 <bslsk05> godbolt.org: Compiler Explorer
20:28:00 <heat> a lot
20:29:00 <Griwes> I think this is the best you can do in current C++ without macros
20:30:00 <heat> is template <typename Type> void f(int) a type or a function?
20:30:00 <Griwes> neither
20:30:00 <Griwes> it's a function template
20:31:00 <heat> I thought of https://godbolt.org/z/rY4bsvMsf but it doesn't work
20:31:00 <bslsk05> godbolt.org: Compiler Explorer
20:31:00 <Griwes> and function templates are a non-first-class citizen
20:32:00 <gog> heat: yu want explicit template specialization
20:33:00 <Griwes> there is nothing to explicitly specialize in that snippet in any meaningful to the problem form, I think
20:33:00 <gog> but i'm not sure you can do it on non-member functions yeah
20:34:00 <gog> or a function without a template parameter
20:34:00 <gog> idk
20:34:00 <Griwes> the usual technique to be able to "pass" a function template around is to wrap it in a struct like I've done
20:35:00 <Griwes> or with the template head on the struct instead of on the function
20:35:00 <Griwes> because both types and type templates *are* first-class (at the template level), so you can pass them as template arguments
20:38:00 <heat> https://godbolt.org/z/nn5cGqd5f c++ standard commitee defeated by a macro-y boi
20:38:00 <bslsk05> godbolt.org: Compiler Explorer
20:39:00 <heat> with NON-STANDARD EXTENSIONS
20:39:00 <heat> the boogeyman of commitee people
20:41:00 <Griwes> making that a statement expression seems... unnecessary lol
20:41:00 <heat> well I want the return type if it has one
20:42:00 <heat> s/return type/return value/
20:42:00 <Griwes> just remove the braces and the semicolon?
20:42:00 <heat> oh right that works haha
20:42:00 <Griwes> lol
20:44:00 <heat> Griwes, weird question but how is it legal for a compiler to eliminate malloc/new calls?
20:46:00 <dminuoso> Why would it not be legal?
20:47:00 <heat> it has side effects
20:47:00 <heat> https://godbolt.org/z/MMEh1nf7e
20:47:00 <bslsk05> godbolt.org: Compiler Explorer
20:50:00 <dminuoso> heat: What kind of side effects?
20:50:00 <heat> memory allocation
20:50:00 <dminuoso> Okay, and an executed instruction has heat dissipation as a side effect
20:50:00 <dminuoso> your point being?
20:50:00 <dminuoso> Side effects are a relative thing
20:51:00 <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.
20:51:00 <dminuoso> And I guarantee you its not
20:51:00 <mrvn> Griwes: why not a lambda?
20:52:00 <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.
20:52:00 <dminuoso> Whether we can derive useful information from this is another topic
20:52:00 <mrvn> dminuoso: if your real machine does not behave like the C++ machine then that is your problem.
20:54:00 <dminuoso> Oh yes, that's a direct quote from ISO/IEC 14882:2020(E) `4.1.2 Abstract machine` right?
20:54:00 <dminuoso> I think I read that there.
20:55:00 <Griwes> mrvn, because it's less handy to define outside of the call expression
20:57:00 <Griwes> heat, https://eel.is/c++draft/expr.new#13
20:57:00 <bslsk05> eel.is: [expr.new]
20:58:00 <jimbzy> Howdy
20:58:00 <Griwes> it's an explicit provision to allow for heap elision optimizations
20:58:00 <heat> ahh okay thanks
20:59:00 <Griwes> note that this is *specifically* for new *expressions*
21:01:00 <mrvn> so where is the storage provided then?
21:01:00 <heat> stack for instance
21:02:00 <mrvn> and then removed because nothing uses it?
21:03:00 <mrvn> I don't think this should be legal. The memory is not deleted
21:08:00 <mrvn> There should be a: 13.1 the pointer value produced by e1 is an operand to an evaluated delete-expression
21:13:00 <Griwes> mrvn: but that would be the wrong place to do things to a delete expression ;)
21:13:00 <Griwes> https://eel.is/c++draft/expr.delete#7
21:13:00 <bslsk05> eel.is: [expr.delete]
21:14:00 <Griwes> (specifically the first sentence of 7.1 and the entirety of 7.3)