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=19
09:13:00 <ilovethinking> how do i know if im in protected r=or real mode
09:13:00 <ilovethinking> or*
09:15:00 <ilovethinking> https://wiki.osdev.org/Setting_Up_Long_Mode because the osdev has 2 sections, swtich from real mode and switch from protected mode
09:15:00 <bslsk05> wiki.osdev.org: Setting Up Long Mode - OSDev Wiki
09:21:00 <sham1> Whether your code is within real more or protected mode really depends on how you've booted up. Hell, you might even be directly in long mode's compatibility submode or even the 64-bit submode
09:22:00 <ilovethinking> uhhh well i booted with qemu -kernel, nothing else lol
09:22:00 <sham1> Like if you're using GRUB for example, you'll be in protected mode
09:22:00 <sham1> Okay, then you're in protected
09:22:00 <ilovethinking> thanks
09:23:00 <ilovethinking> also a question related to the forums, wtf does "you are not a member of the require phpbb group"? i have an account but idk how to join the wiki grou[
09:24:00 <ilovethinking> found it
10:12:00 <ilovethinking> .null: equ $ - GDT
10:12:00 <ilovethinking> how do i represent this in GAS
10:14:00 <GeDaMo> I think . is 'here'
10:15:00 <GeDaMo> https://sourceware.org/binutils/docs/as/Dot.html
10:15:00 <bslsk05> sourceware.org: Dot (Using as)
10:51:00 <kof123> https://github.com/madler/zlib/tree/master/contrib/puff Overlapped copies [...] are allowed and common. You should not use memcpy() since its behavior is not defined for overlapped arrays. You should not use memmove() or bcopy() since [...] their behavior -is- defined for overlapping arrays, [...] to do the wrong thing
10:51:00 <bslsk05> github.com: zlib/contrib/puff at master · madler/zlib · GitHub
10:52:00 * kof123 .oO( memcpy_yes_i_mean_to_overlap() )
11:45:00 <node1> Hi
11:47:00 <node1> What is the method for determining the last address of the main memory in hexadecimal when using Linux.?
13:00:00 <mrvn> Other than strings when do you copy stuff with overlaps?
13:22:00 <kof123> you are supposed to gracefully not ask that and instead valiantly jump to benchmarking various memcpy_overlap()
13:22:00 <kof123> a new variant!
14:39:00 <Jari--> hi all
15:10:00 <brunothedev> Jari--: hi
16:59:00 <ilovethinking> hello
16:59:00 <ilovethinking> so basically after entering long mode and when setting the segment registers, some people set all of them to gdt.data, and others set it to 0
16:59:00 <ilovethinking> osdev wikii sets it to gdt.data and phil opp's guide sets it to 0
17:30:00 <ilovethinking> eh i guess ill just set all fo them to 0
18:50:00 <zid> gog: https://preview.redd.it/u27faua0vooa1.jpg?width=960&auto=webp&v=enabled&s=a14dc01ca098fd424a5ae2ad94951eab6c50dc0a
18:53:00 <gog> zid: accurate
18:54:00 <gog> is a valid segment selector required for fs and gs if you're not using fs/gs base?
18:54:00 <gog> i imagine so
18:54:00 <gog> i never really looked very closely at that part of the manual because i can't into smp
19:00:00 <Ermine> Hi gog, may I pet you?
19:01:00 <gog> yes
19:03:00 <zid> no
19:03:00 <zid> oh hey I actually have fsgsbase now don't I
19:03:00 <zid> I should check my cpuinfo
19:04:00 <zid> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl tsc_reliable nonstop_tsc cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse
19:04:00 <zid> 3dnowprefetch osvw ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xsaves clzero arat npt svm_lock nrip_save vmcb_clean flushbyasid decodeassists pku overflow_recov succor
19:05:00 <zid> rdrand, fsgsbase, bmi2, clzero are the ones in there I recognise and know are useful that I don't think I had before
19:13:00 <mrvn> gog: There is no "invalid" for fs/gs. You just might not like what they contain. E.g. they might allow the wrong CPL access. So you should set them for security. Setting them to 0 give an error on use and setting them to data makes them NOPs.
19:13:00 <mrvn> gog: and in long mode the MSRs override loading them because they set the full 64bit base.
19:14:00 <mrvn> override? Accompany? Are any of the remaining bits valid? check the docs.
19:14:00 <gog> mrvn: makes sense
19:14:00 <mrvn> Now I wonder if loadin the NULL descriptor and setting fsbase makes FS work or fail.
19:15:00 <mrvn> I assume at least the CPL is still needed.
19:15:00 <mrvn> .oO(but I've been wrong before)
19:16:00 <mrvn> Note: loading 0 takes an exta opcode, the data you already have in a register for loading DS.
19:16:00 <geist> are we talking about 64 bit mode or not?
19:17:00 <zid> gs kinda useful to have set though, if you ever wanna do IRQs
19:17:00 <geist> in 64bit mode you absolutely can set fs and gs to zero, and the underlying fsbase stuff works fine
19:17:00 <zid> fs is for noobs who like threads
19:17:00 <geist> so generally that's the strategy on 64bit kernels: set ds/es/fs/gs/ss to zero and if user space sets them to anything else, just set them back to zero
19:17:00 <geist> ie, it's not valid user state
19:18:00 <geist> but in 64bit mode that's independent of what is in the fs/gsbase MSRs
19:18:00 <geist> basically completely vestigial
19:18:00 <geist> (cs isn't exactly vestigial, it still defines what mode the cpu is in)
19:20:00 <mrvn> geist: do you reset es/fs/gs on every task switch
19:20:00 <mrvn> ?
19:20:00 <geist> yes
19:20:00 <geist> and ds
19:20:00 <geist> and ss
19:20:00 <mrvn> So any program that sets segments and uses them then randomly fails after the first task switch?
19:21:00 <geist> correct
19:21:00 <geist> because it's simply defined as not being part of the user space state. they can fuck with them if they want, but it gets whacked back to zero
19:21:00 <mrvn> I think last decade when I tried x86_64 I saved and restored them.
19:21:00 <geist> fairly certain that's not unique and other systems do it too
19:22:00 <geist> there's probably at best security issues with allowing the kernel to save/restore them, because even if it's ignoring it in 64bit mode, it still would end p loading the shadow state, etc
19:23:00 <geist> i betcha there's some dumbass microarchitectural problem with that somewhere
19:23:00 <geist> it's ne thing for user space to set the regiter and the cpu loads the shadow state out of the GDT, but another thing to then have ring0 code do the same load/reload for user space
19:23:00 <geist> so it's much safer to have ring0 code nevere put anything but 0 in them
19:24:00 <mrvn> it would be a way to detect a task switch. Might be usefull for micro benchmarks. If es == 0: ignore run
19:24:00 <geist> there are other ways to detect it
19:24:00 <geist> also i forget the precise detail, but SS gets hard set to 0 in some particular case, in an interrupt handler
19:24:00 <geist> so tere's already a case where you can't avoid it, because hardware does it already
19:24:00 <mrvn> geist: iirc the TSS sets the SS
19:25:00 <geist> again 64bit mode subtly hanges a bunch of that
19:25:00 <geist> TSS64 doesn't have a SS field
19:25:00 <geist> it's just 7 ISTs
19:25:00 <mrvn> geist: sets it to 0
19:25:00 <geist> clarify.
19:25:00 <mrvn> when you load a stack pointer from the TSS then iirc the SS is reset too
19:26:00 <geist> yah. i thought there was a more subtle case too, even ring0->ring0 where the SS gets reset
19:26:00 <geist> basically, SS is a goner already. hardware will basically set it to 0 in a way that user space could observe
19:26:00 <mrvn> maybe. But at least the stack fault has to reset SS in case that was the reason for the fault.
19:27:00 <geist> except it's not a reason for the fault in user space, because it's not used
19:27:00 <mrvn> user space could be 32bit
19:27:00 <geist> yes i'm 100% talking about 64bit onyl
19:27:00 <geist> with 32bit it's now a mix of both, and if you're context switching 32bit tasks, *then* you ave to save all this state
19:28:00 <geist> but that's 100% a different discussion
19:28:00 <mrvn> Ahh, that's also the reason for save/restore of es/fs/gs, 32bit user space.
19:28:00 <geist> bingo
19:28:00 <geist> that's also why the hardware *does* still load the shadow bits of a GDT segment when you load a segment register, *even in* 64bit moe
19:28:00 <geist> because you may be setting up the state for when you switch to 32bit mode
19:28:00 <geist> and you want the hardware to already be primed for it
19:29:00 <mrvn> .oO(but not wait for it unless you do)
19:29:00 * gog meows in 32 bits
19:29:00 * mrvn breaks gog into 32 bits.
19:29:00 <geist> so the hardware s still active, but in 64bit mode it simply ignores the results of what you loaded into the shadow state
19:29:00 * Ermine pets gog
19:29:00 <moon-child> 32-bit gog implies the existence of long gog
19:30:00 <Ermine> ggoogg
19:30:00 <geist> so yeah a 64bit kernel that supports a 32bit user space has to deal with both cases
19:30:00 <geist> but at least when it's in 64bit mode the state doesn't matter so much. so you'd proably have in your context switch routine code to explicitly zero the segment registers if the thread is known to have a 64bit user space
19:31:00 <geist> and presumably you dont provide a mechanism for a thread to switch states (though i guess you could, via some syscall)
19:31:00 <geist> haha long gog
19:32:00 <gog> there is only short gog
19:38:00 <mrvn> There is at least one: execve()
19:40:00 <mrvn> If you had one to switch a running process then you would need some flag in the executable to map the process in the lower 4G only or things would go bad.
19:40:00 <heat> im bac
19:40:00 <mrvn> heat: winter is coming
19:40:00 <moon-child> hi bac
19:40:00 <zid> we missed you
19:40:00 <zid> I'll lock on first next time.
19:40:00 <moon-child> I'm moon-child
19:41:00 <zid> heat is so drunk he's literally just the concept of BAC
19:42:00 <mrvn> don't breath on a candle.
19:43:00 <heat> how does the moon have a child
19:43:00 <heat> does it have a penis and/or vagina
19:43:00 <mrvn> how does the child feel when their mother disappears once a month?
19:43:00 <zid> it means his mother was a hippie
19:43:00 <heat> or did you get starfished into existence
19:45:00 <sakasama> mrvn: Those were always the best days for me.
19:46:00 <mrvn> heat: when a commet really really loves the moon and smacks into it with enough force a bit of moon will break of and become a child.
19:51:00 <mrvn> On that topic: How do flat earthers explain away the phases of the moon?
19:56:00 <moon-child> one of the lizard people curls into the fetal position and rolls across the surface of the projector
19:57:00 <mrvn> .oO(maintainance cycle for the light bulbs)
20:13:00 <geist> mrvn: hmm, that is interesting. i assume there's no limitation of execing a binary of another bitness
20:13:00 <geist> never thought about that
20:14:00 <mrvn> geist: the limit really is just that you can't address anything above 4GB. Even if you map the higher pages into the lower 4GB the address would be all wrong. Unless the code was compiled for the lower address and you are just mapping it there yourself before switching.
20:15:00 <geist> saure, but since the aspace is getting swapped out the kernel can basically just reconstruct it with the new limitation (or lack of in the case of 32 -> 64)
20:15:00 <mrvn> It would be strange but you could have a 64-bit dynamic loader that loades 32-bit code and then switches.
20:15:00 <geist> but i guess it still has to keep the same PID, it just has to switch the mode of the thread
20:16:00 <mrvn> oh, you ment execve()
20:16:00 <geist> yah
20:17:00 <geist> this is no real big deal, but it is the case where a thread would need the kernel to switch its mods
20:17:00 <geist> mode
20:17:00 <mrvn> I think the code doesn't really care if it's 64bit or 32-bit. You load the new executable (the INTERP at least) into memory and then copy the PID and open FDs into the new task struct and keep the old task struct for cleanup purposes.
20:17:00 <geist> yeah mostly just data structures that might need to be tweaked int he kernel
20:18:00 <mrvn> Should be all the same for 64bit -> 64bit, 32bit -> 64bit or 64bit -> 32bit.
20:18:00 <geist> i believe we're violently agreeing
20:18:00 <mrvn> yep. It's a fun thing though to implement that switch.
20:19:00 <mrvn> Also: don't forget x32. long mode with zero extended 32bit pointers.
20:19:00 <geist> yah, aside from limiting the aspace, i wonder if there's anything else the kernel needs to do for that
20:19:00 <geist> probably not
20:20:00 <mrvn> Nothing I'm aware off. It's real simple to implement.
20:20:00 <geist> yah we've talked about it off and on for fuchsia, but both x86 and arm, but never did it. mostly a toolchain issue
20:20:00 <geist> i dont think the kernel needs any tweaks, since we can just in user space limit the aspace via subdividuing the root VMAR
20:20:00 <mrvn> But if you don't start with that in the design then retroactively changing all the places the kernel allocates and returns some address can be hard.
20:21:00 <mrvn> typedef void * kernel_resource_handle; *BOOM*
20:21:00 <geist> yah zircon doesn't have the problem sicne the kernel never allocates something arbitrarily like that. it's capability based, so you're always allocating within a container, and by default the starting container is the entire aspace
20:21:00 <geist> but you can subdivide it such that you limit the aspace to 0-4GB by just splitting the root vmar and then throwing away the top part
20:22:00 <geist> now there's no handle for anything in user space to map anything > 4GB, even if it wanted to
20:22:00 <mrvn> any struct with a pointer in it shared between user/kernel needs handling.
20:22:00 <geist> not so sure, because either it's mapped or not. if it's not mapped then usual mechanism will handle it
20:23:00 <mrvn> I'm talking about the space it takes. The sizeof(struct) differs.
20:23:00 <geist> it's as you say, only in cases where thek ernel allocates space in user space aspace. needs a limiter of some sort
20:23:00 <geist> oh. hmmm. yeah that's true
20:23:00 <heat> linux has learned many lessons there
20:23:00 <geist> i dot think we have any of those in zircon, but it's a thing, yeah
20:23:00 <mrvn> I'm thinking stuff like IO vecs for readv()
20:23:00 <heat> you won't find any new structs without fixed size members
20:23:00 <geist> ah yeah. iovec. that's a problem. *or* you declare that even in x32 mode it's still 64bit iovecs
20:23:00 <heat> i.e struct S{u64 ptr; u64 size;} vs struct S{void *ptr; size_t size;}
20:24:00 <geist> yah. i'd probably declare somethingl ike a k_iovec and then hard u64 it
20:24:00 <mrvn> and let the libc handle the change from char* to u64.
20:24:00 <geist> for zircon at least i think that may be the only real place where a pointer goes across that boundary. also size_Ts, but we can just declare that they're 64bit too
20:25:00 <geist> r at least i guess the other way of doing it is to declare a x32 world to be entirely a user space concern. and it's user spaces problem to bump it up to 64bit values when crossing syscall boundary
20:26:00 <mrvn> It's too bad C doesn't have a Must-Be-Zero type. Maybe you could abuse the nullptr_t for that.
20:26:00 <geist> it's not like it's transparent anyway, because by definition x32 is a 32 bit limited 64 bit ISA
20:26:00 <nortti> mrvn: for explicit padding?
20:26:00 <mrvn> geist: that's what I did. The libc has a bunch of stuff it pretties up for the kernel anyway. What's 4 or 5 pinter to u64 converts more?
20:26:00 <geist> yah
20:27:00 <mrvn> nortti: yes. struct { void *buf, nullptr_t mbz; }
20:27:00 <mrvn> Assuming the implementation uses 0 for NULL.
20:31:00 <bnchs> hiii
20:32:00 <geist> 'lo
20:33:00 <heat> i'm taking this covid time to finally write the ebpf interp
20:33:00 <mrvn> *this* covid time?
20:33:00 <heat> ebpf looks like it maps very well to hw
20:33:00 <heat> probably because this time they did want something more generic
20:34:00 <heat> that is indeed designed to be jitted, that is
20:34:00 <heat> yes mate i have covid
20:34:00 <mrvn> Must be mild if you are still coding. get better anyway.
20:35:00 <EthicsGradient> heat: sorry mate get well soon mate
20:35:00 <heat> thanks
20:36:00 <heat> i've been mostly ok but 1st day I was feverish as shit
20:36:00 <heat> got up to 39C this morning :v
20:36:00 <EthicsGradient> heat: i had 39C fever on the first day when i had it too
20:36:00 <EthicsGradient> was rough
20:58:00 <brunothedev> how does microkernel works? 1. How does loading works, i've seen things like loading .so files in weechat, but it still weird for me 2. How do you load a filesystem driver without the filesystem?
21:00:00 <GeDaMo> 'microkernel' doesn't have to mean the filesystem driver isn't loaded along with the kernel, it means it's not in the same protection level
21:00:00 <danlarkin> you can bundle the code in the same binary, but just run part of it in userspace
21:01:00 <GeDaMo> The bootloader can load everything necessary
21:02:00 <brunothedev> microkernel is usually separated into multiple files, like minix have a lot of "*.gz" files
21:10:00 <gog> so does linux
21:10:00 <gog> a microkernel is a squishy concept anyway
21:11:00 * lav is a squishy concept
21:11:00 * gog squish lav
21:11:00 <lav> uwu
21:21:00 <brunothedev> the fact that i have vim, neovim and emacs on my dotfiles makes me fear when i walk down a road
21:22:00 <gog> imagine using anything but ed smh
21:23:00 <brunothedev> ed is bloat, i write c programs to acess the file and change it
21:24:00 <lav> there should be ed-mode for emacs
21:24:00 <gog> how do you write the c file tho
21:24:00 <brunothedev> gog: the "echo" command, every time it fails, i rewrite everything
21:25:00 <gog> nice
21:25:00 <brunothedev> echo '#include stdlib.h' >> main.c
21:25:00 <brunothedev> echo '#include <stdlib.h>' >> main.c
21:25:00 <gog> heredoc
21:25:00 <heat> theredoc
21:26:00 <lav> neither-here-nor-theredoc
21:26:00 <heat> whatsupdoc
21:26:00 <lav> allgoodoc
21:26:00 <brunothedev> ls | grep '*doc'
21:27:00 <lav> girldoc
21:27:00 <brunothedev> docdoc
21:28:00 <gog> what's updoc
21:28:00 <lav> allgoodoc
21:28:00 <brunothedev> scdoc
21:28:00 <brunothedev> (Santa Catarina Doc)
22:48:00 <brunothedev> you know what? I am gonna write my own bootloader
22:48:00 <bnchs> brunothedev: how are you gonna write one?
22:49:00 <brunothedev> bnchs: probably an MBR bootloader that loads another bootloader
22:49:00 <brunothedev> aka. chainbooting
22:57:00 <geist> yah usually microkernels have some sort of secondary loader that can load both the kernel and at least critical driver processes at boot
22:57:00 <geist> or, you use some sort of ramdisk for the initial boot system, which is why linux + everything in a module + initrd kinda looks like that if you squint at it
22:58:00 <geist> difference there of course is linux modules will evcentually run at ring0, whereas a microkernel functionally the same thing runs in user space
22:58:00 <geist> so the tricky part is bootstrapping the very first process
22:58:00 <heat> why is the ebpf verifier a single 17kLOC file
22:58:00 <geist> can be done by linking it as a flat binary that the kernel knows how to load, or the secondary loader puts into ram so the kernel branches into it
22:58:00 <geist> then from then on out all further user space proceses are started from that one
23:11:00 <mjg> hm
23:11:00 <mjg> sup mofos
23:11:00 <mjg> there are at 2 least 2 distinct G papers pointing out detrimental effects of i-cache pressure
23:12:00 <mjg> and yet G deploys golang binaries, which are all statically linked
23:12:00 <heat> hi mjg
23:12:00 <mjg> this gotta be PESSIMAL on that front
23:12:00 <heat> what does that have to do with icache pressure
23:12:00 <mjg> they all carry "libc"
23:13:00 <mjg> instead of sharing it
23:13:00 <mjg> memset et al
23:13:00 <heat> yes and realistically how much do you actually share in terms of TLB/icache?
23:13:00 <mjg> i'm assuming different binaries here
23:13:00 <moon-child> 1. probably, they consider the organisational advantages worth it. Also, go is slow mostly because they wrote their own compiler and sucked at it, not because of i$
23:13:00 <moon-child> 2. probably go is usually deployed by them as one big server, so it doesn't really have anything to share with
23:13:00 <zid> I bet google also mostly runs things on 96 core machines or whatever these days, and the icache hit rate is low anyway
23:14:00 <heat> and how does this affect things if you consider that shared linking has shit codegen
23:14:00 <zid> so making it worse to make development time cheaper is fine
23:14:00 <mjg> i once more refer you to their papers, which claim a 1% win from icache == millions of dolars in savings bro
23:14:00 <moon-child> oh, go gc is also crap
23:14:00 <mjg> :]
23:14:00 <moon-child> prioritising latency above all else
23:14:00 <zid> that's what papers are for
23:14:00 <mjg> all the papers also way postdate go
23:14:00 <zid> not what businesses actually do
23:15:00 <moon-child> which might almost make sense for interactive stuff, but which makes no sense at all for network stuff
23:15:00 <mjg> their papers claim it is all taken from real prod
23:15:00 <zid> I'm sure the data is
23:15:00 <zid> and I'm sure the calculation is accurate
23:15:00 <mjg> moon-child: i don't know the realities of golang, justp ointing out the apparent contradiction
23:15:00 <zid> did that mean that 20 seconds after the paper, they had a huge drive and reduced server load by 1%? no.
23:15:00 <heat> mjg, why are you assuming there's a contradiction?
23:15:00 <mjg> the claim is changes got eployed and resulted in saforementioned savings
23:16:00 <zid> all my googler friends spend all day writing python and shit to run random queries on their giant datasets that have optimized *backends* written in C or whatever
23:16:00 <mjg> heat: i'm saying worrying about icache does not mesh with deploying several different *static* binaries
23:16:00 <heat> static linking does result in smaller binaries
23:16:00 <moon-child> I guarantee you better gc and better codegen would make a way bigger difference than dynamic linking
23:16:00 <mjg> i'm not saying it would not
23:16:00 <mjg> clearly the results they got were NOT from go workload
23:17:00 <moon-child> afaik google perf sensitive stuff is all c++ anyway
23:17:00 <mjg> ... as they were patching libc or replacing parts of it
23:17:00 <heat> you are assuming that having multiple binaries that dynamically link the same .so does result in good TLB + icache sharing
23:17:00 <moon-child> go is good-enough performance for fungible devs
23:17:00 <mjg> moon-child: 's what i'm saying
23:17:00 <zid> moon-child: yup, it's the "products" that are in the fancy languages
23:17:00 <zid> that random beta they will shut down in 4 weeks
23:17:00 <mjg> heat: i am, yes
23:17:00 <heat> do you have any data to back this up?
23:17:00 <zid> before anybody tries to optimize it and sell it as a real product :p
23:18:00 <mjg> heat: well it results in some degree of sharing by definition, so to speak. how much of a difference does it make -- who knows
23:18:00 <zid> https://killedbygoogle.com/ I bet a lot of these were in Go.
23:18:00 <bslsk05> killedbygoogle.com: Google Graveyard - Killed by Google
23:18:00 <mjg> heat: they claim replacing glibc memcmp which wsa 6 kb in size(!) with something smaller gave them a win
23:18:00 <zid> Their actual core business isn't
23:18:00 <mjg> so
23:19:00 <heat> mjg, yes but how much sharing and how does that compare with the benefits of static linking
23:19:00 <heat> and how much sharing /on their workload/
23:19:00 <mjg> so for example memcmp is used a lot by most code and in this cae it would be fully shared
23:20:00 <heat> yeah and conventionally it also requires a freaking indirect call
23:20:00 <mjg> ye there is overhead from it for sure
23:20:00 <heat> and then things are more spread out in memory, so your TLB hit rate probably won't be as good
23:21:00 <mjg> something like glibc could be backed by a huge page
23:21:00 <heat> etc. i don't think it's as clear cut as "gogle stopid"
23:21:00 <mjg> and it is used a lot
23:21:00 <zid> google too big to care
23:21:00 * moon-child still doesn't understand why you can't patch the plt to do a direct jump
23:21:00 <mjg> they literally wrote a fucking paper claiming they do care
23:21:00 <heat> google is not too big to care
23:21:00 <mjg> in fact 2
23:22:00 <moon-child> I've been told there's concurrency issues, but cross-modification is sound if aligned
23:22:00 <mjg> that i know of
23:22:00 <zid> 'they' = random engineer in a few hours for his next eval to look good
23:22:00 <heat> what do you think the kernel teams do?
23:22:00 <mjg> ye i admit for all i know the paper got burried and realities of production are like they used to be
23:22:00 <heat> eat rocks?
23:22:00 <zid> googl engineers spit out thousands of papers that go nowhere a year I'm sure
23:22:00 <mjg> :]
23:22:00 <heat> getting a 1% win is a fucking win and a half
23:22:00 <zid> 800 of them are w3c standards that they implemented in chrome 3 years ago at least
23:23:00 <mjg> btw is there a problem making go use llvm as a backend/
23:23:00 <mjg> to actually optimize the code
23:23:00 <moon-child> there's a 'gccgo'
23:23:00 <heat> in theory you have gcgo
23:23:00 <heat> the problem is that it sucks
23:23:00 <moon-child> but I would guess gcc and llvm are bad at emitting gc barriers and such like
23:24:00 <moon-child> (llvm in theory has an interface for it, but it seems to suck)
23:24:00 <mjg> g has llvm devs
23:24:00 <mjg> probably easier to sort out than to write their own optimizer
23:25:00 <moon-child> wasn't go originally a 'let's hire og unix luminaries and let them do whatever because we can' side project that then turned into an actual thing
23:25:00 <mjg> it was written by people who were at g for years as is
23:25:00 <mjg> e.g., rob pike
23:25:00 <moon-child> probably they want to keep their own code generator for political reasons
23:26:00 <mjg> ye i would expect there is something non-tech at play here
23:27:00 <mjg> the funniest thing about is that the guy claims G people are just programmers, not researches. incapable of understanding of a brililant language
23:27:00 <mjg> :d
23:27:00 <mjg> lemme find it
23:28:00 <mjg> https://youtube.com/watch?v=iTrP_EmGNmw&feature=shares&t=1240
23:28:00 <bslsk05> youtube.com: Rob Pike - From Parallel to Concurrent (2014) - YouTube
23:28:00 <mjg> :]
23:28:00 <mjg> there ya go, go not brilliant
23:29:00 <CompanionCube> wait that was in video? i thought it was in an essay
23:29:00 <heat> mjg, a really high percentage of OG UNIX bell labs people ended up at google
23:29:00 <mjg> i'm not aware of essays on the matter
23:29:00 <mjg> heat: i know, there is plan9 vibes in go :p
23:29:00 <mjg> internals
23:29:00 <mjg> i'm saying they did not sit down to do this shit immediatley
23:30:00 <CompanionCube> well they did lift the plan9 toolchain initially
23:31:00 <heat> didn't ken also work on go?
23:31:00 <heat> or am I misremembering?
23:31:00 <mjg> CompanionCube: that is probably true
23:31:00 * CompanionCube also vaguely remembers that the pseudo-assembly golang has is also from plan9?
23:31:00 <mjg> this is why i consider the above probably true
23:31:00 <mjg> :]
23:33:00 <CompanionCube> https://zchee.github.io/golang-wiki/Plan9/
23:33:00 <bslsk05> zchee.github.io: Plan9 - Go Programming Language Wiki
23:33:00 <CompanionCube> better source: 'The assembler is based on the input style of the Plan 9 assemblers, which is documented in detail elsewhere. If you plan to write assembly language, you should read that document although much of it is Plan 9-specific. The current document provides a summary of the syntax and the differences with what is explained in that document, and describes the peculiarities that apply when writing
23:33:00 <CompanionCube> assembly code to interact with Go.' from https://go.dev/doc/asm
23:33:00 <bslsk05> go.dev: A Quick Guide to Go's Assembler - The Go Programming Language
23:34:00 <CompanionCube> also https://docs.google.com/document/u/0/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/mobilebasic, 'The “gc” Go toolchain is derived from the Plan 9 compiler toolchain. The assemblers, C compilers, and linkers are adopted essentially unchanged, and the Go compilers (in cmd/gc, cmd/5g, cmd/6g, and cmd/8g) are new C programs that fit into the toolchain.' (of course rewritten for go 1.4 as the documenr
23:34:00 <CompanionCube> describes'
23:34:00 <bslsk05> docs.google.com: Go 1.3+ Compiler Overhaul
23:37:00 <mjg> better show the me essay where he makes the problem with understanding claim
23:37:00 * CompanionCube doesn't have a link, but heard the same story in the past and never watched the video so
23:39:00 <mjg> maybe it came rom the video
23:39:00 <mjg> it is about 9 years now
23:39:00 <mjg> but ye, i would not be surprised if he expressed this numerous times by thatp oint
23:39:00 <mjg> kind of funny to state tho
23:40:00 <CompanionCube> mjg: it does seem to be from a talk: https://www.youtube.com/watch?v=uwajp0g-bY4
23:40:00 <bslsk05> www.youtube.com: Rob Pike about the target group of the Go programming language (golang) - YouTube
23:53:00 <gog> hi
23:55:00 <heat> hi
23:56:00 <zid`> no
23:56:00 <zid`> now what are you going to do!?