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=1&d=8
02:28:00 <newpy> I'm not sure if I'm following the cross-compiler instructions correctly
02:29:00 <newpy> do I download the binutils tar.gz, extract, ./configure & make, then use that to create the compiler?
02:30:00 <Lugar> ye
02:30:00 <Lugar> make sure you're building the cross binutils
02:32:00 <newpy> yes I ran ./configure with --target et al set
02:32:00 <newpy> which gcc download do I need?
02:32:00 <klange> Preferably the newest one.
02:33:00 <newpy> I created a docker container so I don't wreck my main env
02:33:00 <newpy> it came with gcc 9.3.0
02:33:00 <klange> That's mostly irrelevant.
02:33:00 <Lugar> that version is pretty new
02:33:00 <klange> Barring a handful of times older gccs have been unable to compile newer gccs.
02:34:00 <klange> We have a couple of different guides for cross-compilers; if you're following the one that instructs you to build a bare elf target, the latest version is always worth grabbing.
02:35:00 <klange> If you're following one of the sections on adding your own target, the files move around between different versions of gcc so you may need a particular release to match up with the instructions.
02:37:00 <heat_> what error do you get?
02:37:00 <heat_> what's the actual problem?
02:38:00 <geist> also get a pretty new binutils too. usually the most current
02:39:00 <heat> and its not 2.9 ;)
02:39:00 <klange> A perennial issue is people mastakenly downloading very old versions of binutils because of how the directory sort worked
02:40:00 <geist> yah, exactly
02:41:00 <heat> its a classic
02:41:00 * kazinsal blinks and realizes people are still building their own -elf-generic crosscompilers
02:41:00 <heat> c l a n g
02:42:00 <kazinsal> I just use the script and then alt tab and come back to an installed toolchain after an FFXIV dungeon
02:49:00 <newpy> I think it's going ok
02:49:00 <newpy> just wanted to double-check, make all-gcc is taking a bit
02:51:00 <newpy> oh, which script is that?
02:51:00 <klange> gcc is very big, regularly takes a half hour
02:57:00 <geist> there are many scripts. lots of folks put them together
02:57:00 <geist> i have one, but didn't want to push my stuff on others
02:57:00 <newpy> ah yea I think I saw a page of them earlier, but paradox of choice kicked in
02:58:00 <geist> well, depends on if you want to go through the effort to learn/etc or if you just wanna toolchain now
02:58:00 <newpy> not sure if this is on-topic, but is there an OS text any of you recommend over others?
02:59:00 <geist> if the latter then i recommend https://github.com/travisg/toolchains
02:59:00 <bslsk05> travisg/toolchains - Shell script to build gcc for various architectures (32 forks/53 stargazers/MIT)
02:59:00 <heat> there are two great ones
02:59:00 <newpy> well I don't know how much I learned by downloading binutils, gcc, and running ./configure and make haha
02:59:00 <heat> the tannenbaum one and the dinosaurs one
02:59:00 <heat> operating systems concepts is the dinos one iirc
02:59:00 <geist> newpy: also i have a bunch of prebuilts for linux and whatnot if you dont mind using something like that
02:59:00 <geist> https://newos.org/toolchains/
02:59:00 <bslsk05> newos.org: Index of /toolchains
03:00:00 <heat> imo you don't really need a script
03:00:00 <heat> unless you do it a lot
03:00:00 <newpy> is .xz superior to .gz?
03:00:00 <geist> yes
03:00:00 <heat> it's not hard to build a trivial cross compiler
03:00:00 <heat> nyes
03:00:00 <newpy> and tar -xf can handle it?
03:00:00 <geist> yes
03:00:00 <heat> also nyes
03:00:00 <geist> if not you can decompress it separately, etc
03:01:00 <heat> .xz gets you smaller files but its way slower to decompress
03:01:00 <geist> i woudln't say way slower, but slower. it's much faster than bzip2 to decompress, for example
03:01:00 <geist> somewhere in the middle
03:01:00 <Lugar> unless your pc is from 1994 xz should be fine to decompress
03:01:00 <heat> and your tar may possibly not support some formats, gzip is the best one for portability
03:01:00 <heat> negative, i've seen some slow xz decompression on my rpi
03:01:00 <geist> sure, i didn't say it wasn't slower.
03:02:00 <heat> anyway , .zst is the best
03:02:00 <heat> use it
03:02:00 <Lugar> facts
03:02:00 <heat> all praise zstd
03:02:00 <geist> fine. anyway, tar supporting it is just a convenience, you can always decompress and stream
03:02:00 <geist> xzcat foo.tar.gz | tar xv, for example
03:02:00 <geist> or xz -dc, etc
03:03:00 <heat> yes
03:03:00 <geist> tend to have to do that if using an older distro or some of the BSDs or whatnot
03:03:00 <geist> their tars dont necessarily know about newer formats
03:03:00 <heat> or sadly, zstd
03:03:00 <heat> ubuntu's GNU tar doesn't know what zstd is
03:04:00 <geist> what a convenient format
03:04:00 <heat> ubuntu being stuck on old software isn't zstd's fault *shrug*
03:04:00 <geist> i always triple-base64 it too
03:04:00 <geist> that gets you maximum convenience
03:05:00 <newpy> this snark is too high-level for me
03:05:00 <geist> newpy: in general lots of stuff is distributed .gz .xz and .bz2 nowdaays. gz for max compatibility and the others because they compress better
03:06:00 <geist> best of all worls. if you have a 90s era machine or a raspberry pi, use gz
03:06:00 <newpy> I'm just using Ubuntu WSL, testing on Bochs
03:06:00 <geist> bzip2 was the hotness for most of the 2000s, but i thik there's no real compelling reason to use it anymore over newer stuff like xz and zstd
03:06:00 <newpy> should I be testing on virtualbox or something instead?
03:07:00 <geist> when just getting started, bochs is fine
03:07:00 <newpy> ok
03:07:00 <newpy> I was manually using gcc and ld flags to get it to work
03:07:00 <newpy> then came across osdev
03:07:00 <geist> it tends to be a bit simple for the machine it's emulating. qemu is also a good option if you want emulation
03:07:00 <klange> you should test on everything you can manage to get your hands on, but bochs will be helpful early on
03:07:00 <geist> eventually you'll graduate to real machines or virtualbox or vmware or whatnot if you want
03:07:00 <Lugar> for some reason i could never get bochs to work for me. ive always used qemu
03:08:00 <geist> yah, you'll want to do that pretty quickly, but when just getting started its a distraction
03:08:00 <geist> yah i favor qemu, but then i also like to do non x86 stuff, and bochs is a x86 PC emulator only
03:08:00 <geist> whereas qemu is cross platofmr
03:08:00 <klange> bochs's config format and general operation remain a bit tricky to get right
03:08:00 <geist> agreed
03:08:00 <heat> newpy, WSL1 or 2?
03:08:00 <newpy> WSL2
03:08:00 <heat> ah great
03:09:00 <geist> yah no problem
03:09:00 <heat> it's still slower than native but its very usable
03:09:00 <heat> WSL1 feels like you're running the system off an SD card
03:09:00 <geist> otoh when you're just getting started, all your compiles and whatnot will be instantaneous so it's not a big deal even if it's an archaic machine or os
03:10:00 <geist> you have to spend some time typing in enough stuff for the speed to really get to you
03:10:00 <newpy> yea right now it's just handy to be able to code and test on the same box
03:10:00 <geist> like heck, early on your makefile can be just cc *.c for the most part and it doesn't matter that you have to rebuild all the time
03:10:00 <newpy> yea I just had a simple .ld script, playing around with loading from boot
03:10:00 <geist> cool, sounds like you're on your way!
03:11:00 <heat> i've just passed through my nic to a vm
03:11:00 <heat> i feel like this is a solid way to get a few more drivers
03:11:00 <geist> noice
03:15:00 <newpy> heat, you're net booting or?
03:15:00 <heat> no, just regular booting lol
03:16:00 <heat> i've been theorising the past few days that I could just passthrough a regular PCI device like people do with GPUs, and yeah, it works
03:17:00 <newpy> ah
03:17:00 <heat> I was thinking about porting wlan + my wifi adapter's driver to my OS but I'm kind of deciding against that atm
03:18:00 <heat> the driver would need to be imported from linux and the rest of the stack, yeah, I'd need to get it from somewhere
03:18:00 <heat> at least I'm not really feeling writing a whole wlan stack
03:19:00 <heat> probably one of those things where you really need to do a deep dive and know what you're doing
03:19:00 <heat> and I know 0 about wireless in general
03:19:00 <heat> other than "it has channels, it has frequencies, it works"
03:25:00 <newpy> ok got i686-elf-gcc to report --version
03:25:00 <Lugar> yay :]
03:26:00 <Lugar> now start coding
03:26:00 <newpy> yessir
03:36:00 <geist> heat: which vmm are yo using to pass things through?
03:38:00 <heat> geist, qemu through virt-manager
03:39:00 <geist> ah interesting
03:41:00 <heat> it's ridiculously easy, you just add a PCI Host Device and choose the pci device
03:41:00 <heat> *and hope everything IOMMU related works*
03:43:00 <heat> the i915 also has a feature where you can passthrough a virtual intel iGPU to a VM, no unbinding required from the drivers
03:43:00 <heat> which is cool if you want to try it out inside a VM but the emulation is a bit primitive in some aspects
03:44:00 <heat> in the sense that wrong accesses you may be doing actively trigger OOPSes and warnings inside the dmesg log of the host
03:46:00 <geist> i wonder what the virt manager does in this case. there has to be some way to instruct linux to relinquish the device so it can bind to it
03:46:00 <geist> or maybe that's all done via the kvm interface
03:46:00 <heat> yep, there are a few ways you can do it
03:47:00 <heat> essentially you force the driver to unbind itself from the pci device and bind vfio-pci to it
03:47:00 <heat> all using sysfs
03:47:00 <geist> ah
03:47:00 <heat> then it's just a simple -device vfio-something-something with a few options and you're done
03:48:00 <geist> might have to give that a try. i hvae a machine i can totally do that with since it has the extra i210 in it i was hacking on
03:48:00 <geist> but it also has a linux install
03:52:00 <heat> yeah
03:53:00 <heat> honestly virt-manager is super cool since it lets you easily do stuff that may require some tinkering and googling
04:55:00 <geist> yeah, i really should spend more time with it
04:55:00 <Jari--> I am watching this :: https://www.youtube.com/watch?v=w9EHc80HY4U :: Computer Chronicles - Concurrent CP/M
04:55:00 <bslsk05> 'Computer Chronicles - Concurrent CP/M' by Tech Perspectives (00:08:53)
04:56:00 <Jari--> I am wondering if did equally, priotizing, share the CPU to the tasks. Output appears slow.
04:56:00 <Jari--> Probably because of MS-DOS oriented CPU usage, CPU is basically split, not priotized, among the processes tasks.
04:57:00 <heat> old CPUs were slow
04:57:00 <heat> old OSes were slow
04:57:00 <heat> a few days ago I was trying out SVR4 and it was sloooooooooooow
04:58:00 <heat> anything IO at least
04:59:00 <heat> also it rebuilt the unix kernel like 6 or 7 times while installing stuff
04:59:00 <heat> for some reason, it does that
05:00:00 <heat> and I'm honestly scared to find out why it needs to do that
05:09:00 <Jari--> heat: yeah
05:25:00 <CompanionCube> heat: maybe it installed kernel bits?
05:28:00 <heat> a quick google I did told me some similar SCO system relinks stuff for configuration purposes(??)
05:28:00 <heat> so that's probably what its doing
05:28:00 <heat> because the kernel's source definitely isn't there
05:29:00 <Jari--> the memory management for traditional UNIX systems ain't perfect
05:32:00 <CompanionCube> heat: iirc current openbsd also relinks the kernel regularlu
05:32:00 <epony> Jari--, were 40 years after that
05:32:00 <Jari--> epony: I mean it is really complex, some systems today in use are basically flat
05:32:00 <heat> CompanionCube, yes but isn't that part of its kernel-internal ASLR?
05:33:00 <heat> i remember something similar to that on the kernel and the libc I think
05:33:00 <heat> also: linux is also working on that feature for the kernel
05:33:00 <epony> Jari--, that's not UNIX-like then
05:33:00 <CompanionCube> heat: yep, that's it
05:33:00 <heat> an optional ASLR where it re-links things and shuffles them around
05:33:00 <Jari--> if my heart lets me do it, I will continue on JTMOS... been heart sick for sometime, but quitting smoking pretty much fixed all problems... 5. day without
05:34:00 <CompanionCube> it relinks the kernel every boot
05:34:00 <heat> Jari--: damn :/ stay strong
05:34:00 <Jari--> epony: oh I mean non-standard UNIX clones or even MS-DOS / CP/M clones.. mostly mean MS-DOS in this case
05:35:00 <Jari--> heat: many people think it is mental, but no way, it is heart usually... and they tell to docs "I have anxiety" - thats heart usually, asked my surgeon, it is so.
05:35:00 <epony> commerce and adaptations are.. just non-standards territory
05:35:00 <geist> yeah old unix kernels you usually did that: relink the kernel for your particular hardware config
05:35:00 <geist> same with non unix kernels, i think you did similar things for various DEC based oses. was common
05:35:00 <heat> geist, what did they link-in/out?
05:36:00 <geist> basically yuo statically config that you have N disk drives, etc
05:36:00 <geist> makes sense when your kernel is like 20KB
05:36:00 <geist> dunno if it acutlaly skipped linking drivers in too, but probably
05:36:00 <heat> because I saw it relink the kernel when I installed a package from one of the floppies
05:36:00 <geist> certainly was generally in an era beforethere were kernel modules
05:36:00 <clever> in the really old days of rpi, the base address for the gpu firmware was set at link time
05:37:00 <epony> a kernel tuned to the HW is not that wrong of an idea anyway (especially if it's automated) and includes system randomisations that make it non-static (known faults)
05:37:00 <clever> and they released something like 20 builds of the firmware
05:37:00 <geist> and if you didn't have a bus to detect it, then you basically have to hard link it that way, or at least have some sort of config
05:37:00 <heat> geist, hey the svr4 is actually pretty advanced, it even has ELF shared objects!
05:37:00 <clever> each a different offset from the end of ram, so the firmware has more or less ram available
05:37:00 <clever> because they lacked the ability to relink it at runtime
05:37:00 <geist> heat: sure. but the kernel was probably still a monolith
05:37:00 <clever> or boottime
05:37:00 <geist> actually that is a good question: when did kernel loadable drivers come along. i've heard VMS had it back in the 80s, but probably not initially i bet
05:38:00 <geist> i'm guessing by late 80s some of the advanced unices started doing loadable drivers
05:38:00 <geist> sunos, etc
05:38:00 <epony> the modern systems have machine dependent and independent separation, also system interfaces and device specific separation
05:39:00 <epony> so that "kernel arch" problem set is diminishing
05:39:00 <geist> yah
05:39:00 <geist> even fiddling with an old linux 1.0 era on a 386 or 486 you get into the 'kernel cant detect device' problems you get with MS-DOS
05:39:00 <geist> you want your soundblaster to work? gotta configure it in the linux kernel config or on the command line
05:40:00 <heat> du -s /unix says 2090 -> 2090 * 512 bytes = ~1MB
05:40:00 <geist> also i distinctly remember spending lots of times manually configuring netbsd kernels for various sparcstations
05:40:00 <epony> yes, each system walks the evolutionary path to some modern variant
05:40:00 <geist> you'd go in and edit the netbsd config file to include jsut the drivers you need. and some of them were hard coded
05:40:00 <geist> 'there is a pcnet32 at address X'
05:41:00 <clever> that sounds like typical ISA bus problems, there is no real way to auto-detect some devices
05:41:00 <CompanionCube> geist: apparently sunos 4 has kernel moduled at least
05:41:00 <geist> exactly
05:41:00 <geist> CompanionCube: yah probably late 80s?
05:41:00 <clever> device-tree solves the same thing on arm
05:41:00 <epony> how direct and quick that walk is, depends more on the hardware epoch and the team size (rather than 'design' choices and preferences)
05:41:00 <geist> uyah sunos 4 was 1988 +
05:42:00 <geist> sunos 5 (ie, solaris) was SVR4 based and came along in 1992
05:42:00 <heat> clever, you use ACPI for that now
05:42:00 <clever> heat: yep, but can that report ISA cards you added to the system?
05:42:00 <clever> how would the bios discover the card?
05:42:00 <heat> >checks the date
05:42:00 <heat> >2022
05:42:00 <geist> you can imagine the problem immediately shows up with any hw maniufacturer like DEC or Sun or whatnot when they start having lots of devices in the field
05:42:00 <heat> no ISA cards added.
05:42:00 <clever> heat: your avoiding the problem by just not having an isa slot :P
05:42:00 <geist> and then they need to start getting fancier about device detection
05:43:00 <clever> but thats not fixing the problem
05:43:00 <epony> so a modern functional system needs to support some 20-25 years of arches (which still run in production) and that defines the epoch
05:43:00 <heat> the ISA bus was a bad idea
05:43:00 <heat> ACPI fixes it
05:43:00 <geist> clever: honestly i never looekd into isapnp, bt there *was* a scheme for it
05:43:00 <heat> those same PNP numbers are still used by ACPI
05:43:00 <geist> i dont know precisely how it worked, but there was some sort of scheme for isapnp devices to publish their stuff and be autoconfigured
05:44:00 <epony> a post-modern one supports the last 5-10 years and that's it.. 64bit stuck in a compiler feature sets
05:44:00 <geist> usually later stuff. soundblasters in the the late early 90s, etc
05:44:00 <clever> it feels like the only way to do isapnp, is to publish some config beside some magic numbers
05:44:00 <clever> and then just read the entire addr space looking for magic numbers
05:44:00 <clever> but what about mmio, where reads have side-effects?
05:44:00 <geist> yah i never looked into how it works, but i've seen it sort of work. for example if you run the soundblaster PNP utility on some 486 i have it sees the SB but it also sees the 3com network card
05:44:00 <geist> whcih is also isapnp
05:45:00 <geist> so it must have done some sort of bus scan to determine all the pnp things
05:45:00 <clever> i remember windows 95 having a button to manually trigger a scan, and a warning that it can crash the system
05:45:00 <geist> yah. early linux (and probably current linux) has some isapnp stuff too
05:45:00 <geist> 'i found your soundblaster at port X via isapnp' kinda stuff
05:46:00 <clever> i also have an isa serial card in the other room, its just peppered with jumpers
05:46:00 <clever> so you can manually configure everything
05:46:00 <heat> does that code have cobwebs? :P
05:48:00 <CompanionCube> geist: the BSDs seem to mostly cite sunos 4.1.3 as a basis for their modules
05:48:00 <clever> found that isa serial card
05:48:00 <heat> i was going to say someone out there is still running modern linux on an i386 but sadly it needs an i486 because of cmpxchg :(
05:49:00 <clever> 2 banks of jumpers to configure the IO base addr, for port1 and port2, as one of com1/com2/com3/com4
05:49:00 <Jari--> make[1]: *** No rule to make target 'shellmainfunc.o', needed by 'all'. Stop.
05:49:00 <Jari--> it compiles though well
05:49:00 <clever> and then a huge 3x10 jumper bank, to set the irq for port1/port2 to one of 3,4,2,5,7,10,11,12,15 lol
05:49:00 <Jari--> hire some nerd to fix my shell
05:50:00 <heat> i wonder if dtb and acpi will ever win over the other or if its just going to continue fragmented as always
05:51:00 <heat> fwiw windows 10 on arm64 requires acpi
05:51:00 <clever> heat: i like device-tree a lot more, but ive not really used acpi
05:51:00 <heat> so your dtb will be made into AML inside the firmware
05:52:00 <heat> i.e if you use rpi-uefi on a rpi you'll get your dtb in AML form
05:53:00 <heat> i've never used device tree before but I still like it a lot more :P
05:53:00 <heat> acpi requires a big import of code that's not mine
05:53:00 <clever> device-tree is typically read with libfdt, but the format is pretty simple and you could write your own reader
05:54:00 <heat> libfdt is way way smaller than acpica
05:54:00 <clever> acpi bytecode is also just crazy
05:54:00 <geist> yah libfdt i entirely endorse
05:55:00 <geist> it's simple, doesnt' do what you dont tell it to, and compiles nicely small
05:55:00 <heat> 103797 total <-- my acpica import
05:55:00 <CompanionCube> iirc ARM uses a simpler 'hardware reduced' mode, dunno *how* simpler
05:55:00 <heat> without headers
05:55:00 <heat> CompanionCube, that's optional I think
05:56:00 <heat> well, for one, acpica replaces any sort of chipset-specific drivers you may need
05:57:00 <heat> which is the only plus I can find for it lol
05:58:00 <Jari--> heat: geist: CompanionCube: clever: & friends || Personally I think take a small piece of cake [kernel] and digest that.. this is what I should be doing, day by day etc.
05:59:00 <heat> don't eat cake, eat bread()
05:59:00 <Jari--> not easy to get the whole picture of a complex multitasking microkernel for sure
05:59:00 <heat> ba dum
05:59:00 <heat> tss
05:59:00 <geist> gdt
05:59:00 <Jari--> lots of testing work awaits, bug fixing, etc.
06:01:00 <Jari--> I am going to copy and paste the device API / System from kernel, make it work/compile on top of Linux.
06:02:00 <Jari--> that would require ramdisk driver for the simulated operating system
06:23:00 <Jari--> Show me your linker source code.
06:25:00 <geist> hmm?
06:25:00 <Jari--> Run-time.
06:27:00 <Jari--> They are actually doing setpixel calls on window drawing in some GUIs.
06:27:00 <Jari--> Real-time video, sametime window drawing is visible.
06:41:00 <kingoffrance> the one time i tried isapnp was because irq conflict or some such under linux or bsd. ran a dos util (helpfully, OEM that included the isa card, did not include this utility, had to download from vendor). and toggle some thing in BIOS. point: it was easier just to do things manually in my brief experience
06:42:00 <kingoffrance> plug and pray :)
06:43:00 <kingoffrance> its more the OEM fault maybe, old systems actually did have good documentation somewhat
06:44:00 <kingoffrance> if default config with windows 95 didnt need that, you cant blame them for not bothering
06:44:00 <kingoffrance> you have already gone to "unsupported" territory
06:46:00 <kingoffrance> same situation can be compared to dos drivers for "integrated" sound. may exist, may not -- if its not the supported OS, good luck :)
06:55:00 <kingoffrance> i believe i still had to change a jumper for "isapnp" mode anyways as well... "convenient" perhaps only if things were already set up that way
08:08:00 <zid> https://archive.org/details/opera_202201
12:20:00 <geist> was watching a vid on the famicom disk system. kinda curious what the disk rom looked like
14:24:00 <Oli> Do you mean all the data gaps in original Famicom Disk System software disk data structure?
14:51:00 <Jari--> hi all again
14:58:00 <sham1> Hello Jari
15:10:00 <zid> my attention span needs work
15:10:00 <zid> "wow, my arm kinda hurts, I wonder why"
15:10:00 <zid> 10 minutes later I realize it's because I got a covid booster earlier
15:10:00 <GeDaMo> Doh! :P
15:11:00 <clever> heh
15:11:00 <gog> ope
15:24:00 <zid> Anyone wanna buy some of my blood? It's on sale today
15:24:00 <gog> i could use a pint, they took a lot from me yesterday
15:40:00 <GeDaMo> https://i.imgur.com/kk532w9.mp4
15:40:00 <bslsk05> 'Imgur' by [idk] (--:--:--)
15:54:00 <zid> that's how I was found
16:06:00 <sham1> CAT
16:07:00 <gog> mew
16:13:00 * Jari-- writes a note on himself, do not write code intoxicated ever :-)
16:13:00 <Jari--> sh is broken
16:22:00 <zid> wemtac
16:39:00 <Jari--> zid: lots of fun with 64-bit char * -pointers
16:40:00 <Jari--> char arrays
16:40:00 <Jari--> Array of Strings in C
17:31:00 <GeDaMo> https://v.redd.it/2cgics5xyda81/DASH_360.mp4
17:31:00 <bslsk05> '2cgics5xyda81' by [idk] (--:--:--)
17:32:00 <vdamewood> I'm weary of clicking on an MP4 file.
17:33:00 <GeDaMo> It contains moving images of cows :P
17:33:00 <GeDaMo> No audio
17:36:00 <zid> It's a trick, the brown ones are just small and far away
17:37:00 <clever> https://godbolt.org/z/K3EGEMb8c ive got a question involving -mcmodel=tiny on aarch64
17:37:00 <bslsk05> godbolt.org: Compiler Explorer
17:37:00 <clever> the only difference i can observe in the compiled code, is each printf call is one opcode shorter, when dealing with the ptr to the format string
17:37:00 <zid> I've got an answer but it's wrong
17:38:00 <clever> what exactly is changing there?
17:38:00 <zid> it's using a smaller encoding because you told it to use a tiny memory model with less dynamic range
17:39:00 <clever> but what exactly was `add x0, x0, :lo12:.LC0` doing, to give a bigger encoding?
17:39:00 <zid> lo12
17:39:00 <clever> and what is lo12?
17:39:00 <zid> low 12 bits only
17:40:00 <clever> ah
17:40:00 <zid> presumably if it ended up farther away than 12 bits you'd get a linker error saying the relocation could not be fulfilled
17:40:00 <zid> 'relocation against XBUM_32_12_ADDR_JR could not blah blah' or whatever
17:40:00 <clever> but that makes even less sense
17:40:00 <clever> ah, adr vs adrp
17:41:00 <clever> the tiny side is using `adr x0, .LC0`, i assume that the linker is just going to fill in an addr as an immediate?
17:41:00 <clever> so it basically compiles down to `mov x0, imm`?
17:41:00 <zid> I mean, all addrs are immediates or relative offsets to begin with
17:41:00 <zid> the question is can you get away with using a shorter relative offset encoding or immediate encoding by knowing various bits will be 0
17:41:00 <clever> or even `add x0, pc, offset`
17:42:00 <zid> and the -mcmodel option has informed it that it will definitely be close enough
17:42:00 <zid> to have the high bits be 0
17:42:00 <clever> but then, the question is, what is `adrp x0, .LC0` doing differently, to give you bits 12 and up?
17:42:00 <zid> can't you just turn the machine code column on?
17:43:00 <zid> godbolt broke itself in ff again yesterday and I haven't fixed it yet and I was too lazy to open chrome and paste the link, rip
17:43:00 <clever> ah, hadnt seen that button before
17:43:00 <zid> ReferenceError: queueMicrotask is not defined
17:44:00 <zid> whatever.. that means
17:44:00 <zid> some node wankery I guess
17:45:00 <zid> ah no it's normal html
17:45:00 <GeDaMo> godbolt stopped working for me a while ago but I use an old version of Firefox
17:46:00 <zid> same
17:46:00 <zid> I noticed a couple days ago
17:46:00 <clever> so the default model, loads 0x40_0000 into x0, then adds 0x928, to get the final addr
17:46:00 <GeDaMo> I'm sick of the upgrade treadmill :P
17:46:00 <zid> it used to be broken but I had an addon to fix it
17:46:00 <zid> something to do with regex
17:46:00 <clever> while the tiny model just directly loads 0x40_0910 into x0
17:46:00 <GeDaMo> Oh yeah, I had that a while ago too
17:47:00 <zid> GitHub/GitLab Web Components Polyfill
17:47:00 <clever> both reach the same goal, but i suspect the tiny method has less reach, so yeah, the linker could fail there
17:47:00 <zid> to fix github too
17:47:00 <clever> this feels like something the optimizer should be doing, but it would require bluring the lines between compiling and linking
17:47:00 <zid> yea that's always annoyed me personally
17:47:00 <zid> that it codegens with the rel8 rel32 etc already selected in the instructions
17:48:00 <zid> then the linker can only do very basic relocations to patch it up
17:49:00 <zid> I guess for x86 it isn't a huge deal though as you're never going to break 4GB regardless, but it can be a pain yea on things like arm where you get 12 bit offsets etc
17:49:00 <zid> (and rel8 is always too small)
17:49:00 <clever> my original question (before i noticed the above thing), was about that x86-64 mode, with 32bit pointers
17:50:00 <zid> x32?
17:50:00 <clever> but mcmodel is more about the codegen and linker contract, then pointer side
17:50:00 <zid> than
17:50:00 <clever> yeah, thats the name i was forgetting
17:50:00 <clever> does aarch64 have anything like x32?
17:50:00 <zid> x32 is rad I keep wanting to reinstall my VM with it
17:53:00 <clever> i was also thinking, could you modify the asm rules some, so i can have a statement like "put a pointer to X in reg Y, i dont care how many opcodes you need"
17:54:00 <clever> and let the linker decide later on, what the best option is
17:54:00 <clever> but the problem there, is that the assembler hard-codes some byte offsets as it turns asm into binary
17:54:00 <zid> The problem is you'd also have to convey "This this this and this reg are free, this reg might have the same high bits, ..."
17:54:00 <zid> because the main point of these smaller encodings is that you OR them onto pre-existing high-bits
17:54:00 <clever> i can only see something like llvm being able to solve this problem
17:55:00 <clever> where you use IR to state the above
17:55:00 <clever> and then when translating the IR to binary, you are linking at the same time, and can pick the right model
17:55:00 <clever> but even then, it would require bluring the lines between the IR->binary and linker
17:56:00 <clever> the only other solution i can think of, is something like the old apple fat binary trick
17:56:00 <clever> where the compiler/assembler produces 2 versions of every function (and use -ffunction-sections)
17:56:00 <zid> Just leave it to LTO and let god sort it out later
17:56:00 <zid> like we do for everything else
17:56:00 <clever> and the linker picks the shorter one
17:56:00 <clever> ah, would LTO solve this whole problem as well?
17:57:00 <zid> should do right? the linker only gets the GIMPLE/LLVMIR/whatever and does all the codegen at link time
17:57:00 <clever> yeah, i can see that working
18:01:00 <clever> zid: for x32 to work, i can see 2 basic things being needed, 1: always use 32bit load/store for managing any pointers in ram (i assume that clears the top 32bits?), 2: ensure the kernel ABI will expect 32bit pointers everywhere, and things like mmap only use the lower 4gig of the addr space
18:01:00 <clever> does that sound right?
18:02:00 <zid> you just set sizeof(void *) to 4
18:02:00 <clever> yep
18:02:00 <clever> but the kernel also needs to expect that, or structs in ioctl()'s will be all wrong
18:02:00 <zid> yup, that's the other change, an ABI change for syscalls
18:02:00 <clever> and the kernel must limit mmap to the lower 4gig, or your allocated ram wont fit into your void*
18:02:00 <zid> It already knows about NUMA domains and stuff
18:03:00 <zid> not code it doesn't already have
18:04:00 <clever> i remember the mmap man page having an x86 only flag, to request that memory be in the lower 4gig
18:04:00 <clever> and i had mentioned it, on the subject of fixing some rpi firmware issues
18:04:00 <clever> basically, the messages passed to the closed firmware, had a 32bit field for a userland void*
18:04:00 <clever> so when you get the message back, you can find your own state in userland, and react properly
18:05:00 <clever> and a 64bit void* just wont fit in that field, and they didnt want to deal with fixing that
18:06:00 <clever> my proposed solution, was to just ask mmap to give you something in the lower 4gig of userland, so you can still use a 32bit field to hold its pointer
18:06:00 <clever> but that mmap flag was x86 only
18:07:00 <clever> RPF instead went the far more complex (but better?) solution, of moving all of that interfacing with closed-source into kernel space, and exposing it to userland over existing standard apis like kms and v4l
18:11:00 <clever> for some things like 2d video out, there are 2 solutions
18:11:00 <clever> fkms provides a standard kms api, wrapped around the closed-source firmware, and the kernel can just use opaque tokens in the 32bit field, instead of pointers, and look them up elsewhere
18:12:00 <clever> the kms route, puts linux in complete control of the hw, and the firmware is just not involved anymore
18:12:00 <clever> for h264 and isp tasks, they opted to just move the problem into kernel space, and expose things over v4l
18:13:00 <clever> and then v4l maintainers deal with the 32bit vs 64bit compatability problems, which they already did
18:19:00 <clever> so in theory, aarch64 could have an x32 mode, but it would require changing gcc to make void* 4bytes, creating a new syscall abi, and making the kernel support that abi?
18:19:00 <j`ey> https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/AArch64-Options.html ilp32
18:19:00 <bslsk05> gcc.gnu.org: AArch64 Options - Using the GNU Compiler Collection (GCC)
18:20:00 <clever> already done it seems!
18:27:00 <clever> j`ey: i assume linux's syscall abi already supports ilp32?
18:27:00 <newpy> I was following the bare bones tutorial, but I'm not sure how to get grub-mkrescue to create the iso
18:27:00 <newpy> is it just `apt install grub-common` ?
18:32:00 <bauen1> newpy: you can use https://www.debian.org/distrib/packages to find what package contains a particular file
18:32:00 <bslsk05> www.debian.org: Debian -- Packages
18:32:00 <clever> the apt-file command i think can also do that
18:32:00 <bauen1> newpy: and in this case it is grub-common
18:33:00 <newpy> ty
19:08:00 <zid> oh rad, I found a bizzare link on imgur that sets a cookie that opts you out of the redesign
19:08:00 <zid> so it works again now
19:13:00 <GeDaMo> I just wrote a greasemonkey script for imgur to display the image URL from the page header :P
19:51:00 <newpy> hmm, I think I followed the barebones tutorial correctly, but when I tried to run the iso in virtualbox it said FATAL: No bootable medium found! System halted.
19:51:00 <zid> no idea for vbox
19:55:00 <sham1> Did you create the boot disc image properly
19:55:00 <sham1> Did you actually mount it
19:55:00 <GeDaMo> Are you using the right file? :P
19:55:00 <zid> file it and try mount it
19:56:00 <zid> might be a decent qa test
19:56:00 <newpy> I created the iso according to the tutorial
19:56:00 <sham1> And got no errors I presume
19:56:00 <sham1> Hmm, odd
19:57:00 <Lugar> maybe its a virtualbox issue. try running it in qemu
19:57:00 <sham1> The Bare Bones tutorial ought to be pretty watertight
19:57:00 <zid> If you do do qemu more people can help
20:01:00 <newpy> installing qemu now
20:02:00 <newpy> could also be that I didn't make the cross-compiler correctly
20:02:00 <clever> newpy: even if your kernel was bad, grub should have still booted, and given its own error
20:05:00 <newpy> ah ok, only other issue might be that I created the VM incorrectly (chose Other/Unknown for type)
20:06:00 <newpy> (but also tried Linux)
20:06:00 <sham1> The OS type is just some presets and an icon
20:06:00 <Lugar> i didnt know that :|
20:08:00 <zid> for qemu it's jsut -cdrom blah.iso :p
20:08:00 <sham1> Now you know, and knowing is half the battle
20:09:00 <zid> I think for vmware it sets up the device tree differently at least
20:10:00 <zid> pick win98 and it'll add an ide drive or whatever I assume :p
20:11:00 <sham1> Clearly a SATA drive
20:11:00 <sham1> Or fuck it. nVME
20:11:00 <sham1> Err, NVMe
20:18:00 <newpy> qemu-system-i386: Error loading uncompressed kernel without PVH ELF Note
20:19:00 <Lugar> huh
20:19:00 <zid> what does 'file blah.iso' give
20:19:00 <zid> and if you try to mount it what does that give
20:19:00 <zid> cus it sounds.. fucked
20:19:00 <Lugar> yeah
20:20:00 <Lugar> it sounds like you are loading the iso file with the -kernel parameter
20:20:00 <zid> ooh yea that's a good shout
20:21:00 <newpy> I used `qemu-system-i386 -kernel mykernel.elf` per the instructions
20:21:00 <Lugar> are you using multiboot1 or multiboot2
20:21:00 * zid checks the barebones page
20:21:00 <zid> okay so yea it does suggest that, and it suggests it because it's multiboot, so I guess it failed to find the multiboot
20:21:00 <zid> and tried to boot it like a linux kernel
20:21:00 <zid> then bailed on that also
20:21:00 <newpy> copied from here: https://wiki.osdev.org/User:Zesterer/Bare_Bones
20:22:00 <bslsk05> wiki.osdev.org: User:Zesterer/Bare Bones - OSDev Wiki
20:22:00 <sham1> That's not the Bare Bones tutorial
20:22:00 <newpy> oh
20:22:00 <Lugar> lol
20:22:00 <newpy> let me load up the actual one
20:22:00 <zid> https://wiki.osdev.org/Bare_Bones is, presumably
20:22:00 <bslsk05> wiki.osdev.org: Bare Bones - OSDev Wiki
20:22:00 <zid> that's some user's page
20:22:00 <zid> If it's easy for you to host the ELF somewhere I'd look at it
20:23:00 <zid> That user page was last edited.. 2017
20:23:00 <newpy> somehow zerester made it onto the official (?) tutorial list: https://wiki.osdev.org/Tutorials
20:23:00 <bslsk05> wiki.osdev.org: Tutorials - OSDev Wiki
20:23:00 <zid> okay so it looks like at the time this tutorials page was made
20:23:00 <zid> his was a fork with 'improvements'
20:23:00 <zid> but the normal one has since been updated massively and his hasn't
20:24:00 <newpy> yea going to try the official tutorial and see if that works
20:24:00 <zid> send me the elf :p
20:25:00 <zid> base64 and paste it to a pastebin works
20:29:00 <sham1> "If this is your first operating system project, you should do a 32-bit kernel first." Heh, interesting advice indeed
20:30:00 <Lugar> Too bad i listened to that
20:30:00 <Lugar> i had to reform my whole codebase to switch to x86_64
20:30:00 <zid> x86 is dead, long live x86 (64)
20:30:00 <sham1> It's not like creating a loader for a 64-bit kernel is that difficult. Besides, one gets neat benefits like being able to put the kernel to the -2GiB of the 64-bit address space without stupid linker hacks
20:31:00 <zid> 64bit is freeing in terms of not having to give a shit about vm space
20:31:00 <sham1> Similar benefit also exists for 32-bit kernels
20:31:00 <zid> and also.. on x86.. x86_64 is just way simpler
20:31:00 <zid> once you get over the additional hurdle of 'enabling EFER.LM'
20:31:00 <gog> RIP-relative addressing is bae
20:31:00 <sham1> And the NX bit
20:31:00 <sham1> I love the NX bit
20:31:00 <gog> yes
20:31:00 <gog> NX is bae
20:31:00 <zid> I have it enabled but I've never tested it :P
20:31:00 <gog> i've tested it inadvertently
20:32:00 <zid> gj
20:32:00 <gog> had it enabled for a whole PDPTE
20:32:00 <gog> it worked
20:32:00 <sham1> Nice
20:32:00 <zid> enable it on your whole PML4 or riot
20:32:00 <zid> I mean, isn't that how it's supposed to work though
20:32:00 <zid> you set it on every layer, and it's W^X that matters
20:33:00 <sham1> I'd have to check the manuals, but I'd think that the most specific applicable paging structure might win in terms of "is this executable"
20:33:00 <zid> it's executable if it isn't writeable, is what NX enforces though
20:33:00 <zid> so *everything* should have that bit set
20:33:00 <sham1> I thought that you can do W|X
20:34:00 <sham1> It's just that you shouldn't
20:34:00 <zid> that's the case where you wouldn't set it
20:34:00 <zid> but the parent tables would still have it set
20:34:00 <sham1> Indeed
20:34:00 <zid> I forget if.. I actually bothered to set the bit on anything but the PML4, thinking about it
20:35:00 <zid> I think my mmap just does | PT_PRESENT automatically, not PT_NX | PT_PRESENT
20:35:00 <gog> i thought it inhereted the permissions of the next level up because that's how it worked when i had my little accidental test
20:35:00 <zid> so everything past boot won't be nx enabled
20:35:00 <gog> every page in the 2GB covered by the PD was NX
20:35:00 <zid> oh hmm that also sounds reasonable
20:36:00 <zid> if only there was a manual :( Guess we'll never know
20:36:00 <gog> even though the PTEs were not set NX
20:36:00 <newpy> zid, https://file.io/0mgX0gTlHRwe
20:36:00 <bslsk05> file.io: Download | file.io
20:36:00 <sham1> I think I'll just do things according to PROT_READ, PROT_WRITE and PROT_EXEC in my kernel mmap
20:36:00 <gog> yeah too bad there's no massive book that tells the workings of these things
20:37:00 <zid> it has useable code inside it!
20:37:00 <sham1> Which book
20:37:00 <gog> i wish i had usable code inside me :(
20:37:00 <gog> but everything that i type is trash
20:37:00 <zid> I wonder if I have readelf or if I'll have to copy it to my vm
20:38:00 <sham1> Trash code? Same. It's no wonder that I restart projects every 2 months or so
20:38:00 <zid> multiboot sig is at 0x4000
20:38:00 <zid> can I be bothered to do the checksum or not..
20:39:00 <zid> oh checksum is fine
20:39:00 <gog> sham1: project restarting gang
20:39:00 <sham1> I hate being a perfectionist sometimes. I can't get anything done as my definition of perfection shifts
20:39:00 <zid> It's the same as mine so I didn't have to do math, 1badb002, 3, e4524ffb
20:40:00 <zid> how far does qemu check for mulbitoobt?
20:40:00 <gog> i'd say i'm less of a perfectionist and more an obsessive-compulsive
20:40:00 <gog> zid: standard says it's supposed to look 64K?
20:40:00 <zid> 16k is quite far in
20:40:00 <gog> oh 16
20:40:00 <gog> idk
20:40:00 <zid> 0x4000 is where it is
20:40:00 <gog> that user page with the ldscript has two .rodata sections, does that even work?
20:41:00 <zid> oh my mouse is broken in my VM nice
20:41:00 <zid> scrollwheel spits out control chars to term
20:41:00 <Lugar> i saw that and i got confused too gog
20:41:00 <zid> It does infact have two .rodata
20:41:00 <zid> one at 0x2000 and one at 0x4000
20:41:00 <gog> oh ok then
20:41:00 <gog> if it works it works
20:41:00 <sham1> Double the .rodata, double the fun
20:41:00 <zid> Unless something checks the strtab and stuff to find out, they won't notice
20:41:00 <gog> yeah
20:41:00 <zid> as long as the program headers are fine
20:41:00 <sham1> Lugar: did you check with the grub2 tool if the kernel is a valid multiboot 1 oimage
20:42:00 <gog> i was just thinking that the linker might try to merge the sectiosn and choose the latter
20:42:00 <gog> but idk for sure
20:42:00 <zid> huh that's an interesting 'bug' in readelf though
20:42:00 <zid> it shows program headers as 00 .text .rodata
20:42:00 <zid> but which .rodata? :P
20:42:00 <gog> the world may never know
20:42:00 <zid> I'd have to RE it from the addresses
20:44:00 <zid> okay so qemu source basically does
20:44:00 <zid> if(load_multiboot()) return; if(load_elfboot()) printf("PVH NOTE bullshit");
20:44:00 <zid> so load_multiboot failed
20:45:00 <zid> looks like qemu only checks the first 8k
20:45:00 <zid> https://github.com/qemu/qemu/blob/b1fd92137e4d485adeec8e9f292f928ff335b76c/hw/i386/multiboot.c#L169
20:45:00 <bslsk05> github.com: qemu/multiboot.c at b1fd92137e4d485adeec8e9f292f928ff335b76c · qemu/qemu · GitHub
20:45:00 <gog> i've had trouble with it if PA != VA
20:45:00 <zid> That's why it doesn't boot in qemu, newpy
20:45:00 <sham1> Can someone tell me what the purpose of the paddr even is
20:45:00 <zid> unless those are ints?
20:45:00 <sham1> Does anything actually use it
20:46:00 <zid> in which case it does go to 64k, but maybe it isn't aligned
20:46:00 <zid> but it is aligned, shrug
20:46:00 <gog> grub uses it
20:46:00 <sham1> But why
20:46:00 <zid> it's the.. file offset
20:46:00 <gog> /shrug
20:46:00 <zid> pretty handy imo, knowing where to load things from :P
20:46:00 <sham1> But that's the file offset. I mean the physical segment addresses
20:47:00 <zid> there's no segmentation in elf
20:47:00 <sham1> Program header
20:47:00 <zid> paddr = fileoffset
20:47:00 <zid> file is loaded into memory, then mapped somewhere
20:47:00 <sham1> Oh is it
20:47:00 <sham1> Huh
20:47:00 <zid> you sorta wanna know where it is in memory before you can map it
20:48:00 <zid> which means knowing all the offsets into the file
20:48:00 <newpy> zid, only checks first 8k?
20:48:00 <zid> could be yea
20:48:00 <zid> it *might* be checking 64k depending on how big that pointer is
20:48:00 <newpy> so when I say . = 1M; it's starting way past 8k right?
20:48:00 <zid> that's VMA
20:48:00 <newpy> oh ok
20:48:00 <sham1> Really? The p_addr? I thought that the file offset is p_offset
20:48:00 <zid> your multiboot is at 0x4000 in the file
20:49:00 * geist waves
20:49:00 <zid> note that elf is useful for ROMs and shit too
20:49:00 <gog> you can make it set a p_paddr if you do the AT() attributes on sections
20:49:00 * gog waves at geist
20:49:00 <newpy> I'm not too familiar with .ld scripts, am I doing something wrong there?
20:49:00 <zid> where you might have a weirdly constructed rom
20:49:00 <gog> yeah i think that's mostly what it's for
20:49:00 <gog> platforms that care about that kind of thing
20:49:00 <newpy> I think I'll just use the official barebones tutorial and see if that works
20:49:00 <newpy> not sure what this zerester guy did
20:49:00 <zid> newpy: no idea, but you have .text first at 0x1000, then some crap, then some .rodata at 0x4000 with multiboot in it
20:49:00 <sham1> Yeah. There's p_offset and then p_paddr
20:50:00 <sham1> And of course p_vaddr which is the actually useful one
20:50:00 <geist> right, the paddr stuff is usually ignored by most loaders, *Except* loaders taht are doing more low level embedded stuff or things like grub when not using multiboot
20:50:00 <sham1> Hmrmrm
20:50:00 <geist> and unless you go out of your way PA == VA in most binaries
20:50:00 <zid> A lot of systems give a shit about where you copy the images to the physical memory, it helps not to try to load it to 2GB
20:51:00 <zid> then map it to 1MB
20:51:00 <zid> when you have.. 16MB of ram
20:51:00 <geist> exactly. the canonical example is linking your kernel to run at say 3GB but load at 2MB. in taht case you set your paddr segments starting at 2MB and VA at 2GB
20:51:00 <geist> grub when using ELF (vs multiboot) will honor that
20:51:00 <geist> as well as qemu when using -kernel, etc
20:52:00 <zid> newpy: anyway, the linker script for this is weird apparently, you have two .rodata and they're in a slightly strange order
20:52:00 <geist> but a loader in say linux when loading an app will not pay attention to PA stuff and only use VA
20:52:00 <gog> physical address _hint_
20:52:00 <zid> you should probably make a .header section that's always first, or move your multiboot header into .text which is currently first
20:52:00 <zid> (but linked to be 2nd in memory, weirdly)
20:53:00 <clever> the other case where ive seen paddr and vaddr differ, is with .data living in rom (or flash), and you are copying it to ram on bootup
20:53:00 <geist> a simple example is to do something like .text.multiboot in some ASM file
20:53:00 <clever> the paddr is where the linker places it in the .bin you flash to the hw
20:53:00 <geist> and then in yuor linker script call that out first so it goes near the start
20:53:00 <clever> but the vaddr is what the linker inserts into the executable opcodes
20:53:00 <sham1> I don't like the stuff where one loads the kernel in a physical place and then fixes up the virtual addresses. As far as I am concerned, that's gross
20:53:00 <zid> yea mine just does .text { .text (multiboot.o); .text (*.o); }
20:53:00 <zid> I might have written those inside out..
20:54:00 <zid> I did infact, write them inside out
20:54:00 <zid> my kernel does .text : { boot.o (.text); * (.text); }
20:54:00 <sham1> I'll rather just do separate loading thing that grub can place wherever and then I can load the actual kernel wherever
20:54:00 <zid> "The text section from boot.o, then the text section from everything else"
20:54:00 <gog> maybe they're like me and insist that anything that isn't code should not live in the same page as things that are code
20:54:00 <gog> different things are different!
20:54:00 <sham1> That'd be silly
20:54:00 <geist> yah and if you dont use the .o file stuff you can do it with like https://github.com/littlekernel/lk/blob/master/arch/x86/32/kernel.ld#L33 or something
20:54:00 <bslsk05> github.com: lk/kernel.ld at master · littlekernel/lk · GitHub
20:55:00 <geist> where in that case if you put the multiboot header in a .text.boot section it'll get sorted first when getting combined with other text segments
20:55:00 <zid> the ELF itself doesn't care wwhether the multiboot header is in .text or not, because it'll start executing from the entry point in the header
20:55:00 <zid> not .text
20:55:00 <zid> first in .text or not*
20:55:00 <zid> https://github.com/zid/boros/blob/master/boot/boot.asm
20:55:00 <bslsk05> github.com: boros/boot.asm at master · zid/boros · GitHub
20:56:00 <geist> right, which is why the linker just usually sorts by whatever it feels like
20:56:00 <geist> usually order it showed up on the link line
20:56:00 <zid> https://github.com/zid/boros/blob/master/boot/linker.ld linker script then does ENTRY("start") and .text : { boot.o (.text); * (.text); }
20:56:00 <bslsk05> github.com: boros/linker.ld at master · zid/boros · GitHub
20:57:00 <geist> what i was going to do was explicitly *not* recommend doing the file call out stuff in the linker script
20:57:00 <geist> but whatever works for ya
20:57:00 <geist> since zid is giving you a counter example
20:57:00 <zid> I don't mind for a single .o dep, I know there's a workaround but I learned it afterwards and it does work
20:57:00 <zid> either way you need a hardcode, either on a 'special' section, or a 'special' filename
20:57:00 <zid> whichever you pick is up to you
20:57:00 <geist> for a single i guess it's fine, i just find it generally easier to use special sections
20:58:00 <geist> and iirc the LLVM linker doesn't understand the file thing
20:58:00 <zid> if you ignore it you need a special link line that puts boot.o first
20:58:00 <geist> that eventually sealed it whenwe were porting the linker sripts in zircon over to llvm
20:58:00 <zid> there's no real way to FULLY avoid it
20:58:00 <geist> sure there is. see the script i linked before
20:58:00 <zid> You need the special name,.
20:58:00 <geist> you simply arrange for the special section to go first
20:58:00 <zid> Special name (section), special name (filename), special link (order)
20:58:00 <zid> pick 1
20:58:00 <gog> wooo rudimentary vm allocations
20:58:00 <geist> first one
20:58:00 <zid> :D
20:58:00 <geist> it's more stable
20:59:00 <zid> but then how will I troll windows users by naming two files Boot.o and boot.o
20:59:00 <gog> now i have some refactoring to do because i made a mess :|
20:59:00 <geist> order of link line you should never rely on. i dont think any linker guarantees it
20:59:00 <zid> and Boot.o says "Stop using windows"
20:59:00 <geist> there are any number of switches that would cause the linker to rearrange things
20:59:00 <zid> yea I'd never pick the third
21:00:00 <zid> There's just no 4th option where you need 0 special
21:02:00 <geist> ugh i've got an old gentoo install (last booted in 2019) on this old pentium 3 machine that is a huge mess of not being able to roll forward
21:02:00 <zid> yea fuck that
21:02:00 <geist> i guess i should just reinstall, since emerge takes like 5 minutes to just decide that i can't build
21:02:00 <zid> nuke it, there've been 418 python updates since then
21:02:00 <geist> trying to debug it is too slow
21:02:00 <geist> exactly, it's the python stuff
21:03:00 <zid> There's a reason git shifted from shell scripts to C
21:03:00 * zid stares at emerge
21:03:00 <zid> "Let's pick the thing with the worst possible dependency management, and write our depenedancy manager in it"
21:03:00 <geist> it's paradoxically bad that in my experience gentoo is a great distro for old machines because you end up with an extremely thin system (openrc, only a handful of demons, etc)
21:03:00 <geist> except you have to build everything which takes forever on old machines
21:04:00 <zid> yea my VM is openrc and no daemons besides sshd and ntp
21:04:00 <zid> It's getting pretty hard to get xfce working now though ngl
21:04:00 <zid> have to install bizzare greeters and login managers and shit manually
21:04:00 <clever> zid: nixos just wrote their own functional language for the package manager, and then guile stripped that half out and used scheme to replace it, lol
21:04:00 <geist> but my other experience is gentoo really requires constant updates or you end up in trouble
21:04:00 <zid> I've revived an old install a bunch of times
21:04:00 <zid> but it was never pretty
21:04:00 <geist> re: the python slow on old machines thing you really feel it with ubuntu or debian too
21:04:00 <geist> apt-get and whatnot also sits there and churns for minutes thinking
21:05:00 <clever> geist: yep, ive got a gentoo box i havent updated in 8 years, and i'm dreading if i ever need to touch emerge again, lol
21:05:00 <zid> yea don't bother after 8 years unless you have a fetish and 128GB of ram and 32 cores
21:05:00 <gog> is paludis still a thing?
21:05:00 <gog> i remember a bunch of drama in like 2010 over that
21:05:00 <clever> zid: 2gig of ram, 2 cores, lol
21:06:00 <zid> that can't even build software at all anymore, sorry
21:06:00 <clever> and i'm fearing problems where something like libc updates first, and borks everything else
21:06:00 <zid> gcc won't even look at a .cpp file for less than 4GB
21:06:00 <geist> for soem reason i still have a place in my heart for this old p3. dual pentium 3 500mhz (katmai) 1GB ram
21:06:00 <geist> it's still a pretty usable machine, excep tyou *really* feel the slowness of stuff written in python or modern compilers
21:06:00 <geist> which clearly run an order of magnitude slower than older ones
21:07:00 <geist> one of the reasons i really keep it around is i think it's the only machine i have left around that has both 3.3 and 5v PCI in it
21:07:00 <geist> and i have some old 5v PCI scsi cards
21:07:00 <geist> so if i need to read a scsi disk, this is it
21:07:00 <clever> i remember my gentoo machine having problems at one point, when just LINKING firefox, needed over 3gig of virtual memory
21:07:00 <clever> i was on a 32bit cpu....
21:08:00 <clever> swap cant fix that
21:08:00 <geist> yah i just run this thing headless. not going to bother with a ui
21:08:00 <zid> linking firefox requires dedicated machines for linking firefox (chrome too)
21:08:00 <zid> They're literally the largest two pieces of code in the world
21:08:00 <geist> though i think at some point i loaded up a lightweight ubuntu lxde install and it was alright
21:08:00 <clever> zid: i recently looked at my chrome binary, ~260mb for the elf itself, then i checked the symbols
21:09:00 <zid> linux kernel has more loc I think, but you link like 2% of it at once the rest are individual module links
21:09:00 <clever> the HSTS pre-seeding list, compressed, is 1mb, and the single largest symbol in the binary
21:09:00 <clever> i think its just an array of every domain that supports https, and chrome wont even give you the choice of http on them
21:09:00 <geist> also possible it was trying to LTO link firefox
21:10:00 <zid> at google if you wanan build chrome, your build system kicks it off to a farm, and you come back 10 minutes later
21:10:00 <zid> you CANNOT build it on your dev machine
21:10:00 <clever> zid: ive built chrome on my desktop, i think it took 48 hours
21:10:00 <zid> 40GB of swap? :p
21:10:00 <geist> yah tell me about it. also building clang
21:10:00 <clever> zid: 64gig of swap!
21:10:00 <geist> lots of ram in the first place
21:10:00 <clever> and 32gig of ram
21:10:00 <gog> jesus
21:11:00 <geist> the usual high performance workstations at work are at least 64GB ram, newer ones are 192
21:11:00 <zid> 192 might get it done, if you have enough cores and optanes to actually get some decent amount of lines/sec compiling
21:11:00 <geist> yah my workstation is 72 threads, 192GB ram
21:11:00 <zid> how many optanes?
21:12:00 <geist> 92 optane, go premium!
21:12:00 <clever> geist: oh, i had chrome segfault today, it brought the entire session down
21:12:00 <zid> pfft, I dropped my keyboard and my display driver crashed, beat that
21:12:00 <geist> oh reminds me, i should put a charger on the car. was gonna drive it later, but probably should top off the battery
21:12:00 <geist> brb
21:12:00 <zid> It recovered correctly idk why it was a recoverable crash
21:12:00 <clever> geist: where might something like this get reported? https://gist.github.com/cleverca22/492d9a38bdd9e70769503703006294f9
21:12:00 <bslsk05> gist.github.com: gist:492d9a38bdd9e70769503703006294f9 · GitHub
21:13:00 <clever> zid: ive bumped the hdmi connector on my monitor, and the system locked up, lol
21:13:00 <gog> ope
21:13:00 <zid> hdmi hotplug is megs of code
21:13:00 <clever> zid: the gpu driver didnt properly deal with hot unplug events
21:13:00 <zid> my friend writes all that for nvidia as his full time job :p
21:13:00 <clever> hot insertion is fine, and auto-enables the monitor
21:13:00 <clever> hot removal crashes hard
21:13:00 <clever> you better hope the contacts dont bounce on insertion :P
21:13:00 <zid> actually geist knows him vaguely
21:13:00 <zid> jon mayo
21:15:00 <geist> vaguely
21:15:00 <zid> so yea, that ugly bastard's job at nvidia is writing hdmi hotplug code, seemingly for years
21:16:00 <gog> yaaaay i made a commit today
21:16:00 <zid> because he's still doing it now, after having done it for the switch
21:16:00 * gog quits for the rest of the weekend
21:16:00 <geist> alright!
21:16:00 <zid> gog: good plan
21:16:00 <zid> time to porn the weekend away
21:16:00 <geist> most of my free time has been soaked up with FFXIV lately
21:16:00 <geist> dunno why but i'm on a grinding kick there
21:16:00 <zid> I'd play that if I had disposable income for sure
21:16:00 <geist> since i have like 2700 quests to get up to the end
21:16:00 <gog> nah i'm gonna try to do some more on this vm allocation tomorrow. i need to actually implement the gap-finding algo
21:17:00 <gog> i have a heap now though
21:17:00 <zid> okay then wank the rest of saturday away
21:17:00 <zid> wank the rest of sunday away as a reward for working
21:17:00 <gog> also my heap will break after a certain number of alloc/frees
21:17:00 <gog> i don't have block coalescing
21:18:00 <gog> :|
21:18:00 <zid> https://tenor.com/view/psyduck-gif-21760865 gog irl
21:18:00 <bslsk05> tenor.com: Psyduck GIF - Psyduck - Discover & Share GIFs
21:19:00 <zid> oh fuck that website
21:19:00 <gog> i'm not a duck i'm a cat
21:19:00 <zid> discord direct embedded it I didn't realise it was imageshack 2.0
21:19:00 <geist> Huh you’re using a discord to irc proxy?
21:20:00 <zid> no
21:20:00 <zid> I lifted it off discord
21:20:00 <geist> Ah got it
21:24:00 <sham1> Oh great. The opponent left again
21:24:00 <clever> geist: what do you make of the backtrace in the gist i linked above?
21:24:00 <sham1> How am I supposed to chess when people just leave without resigning
21:25:00 <sham1> Why am I punished for people leaving by having to wait like a minute
21:26:00 <clever> sham1: i saw somebody join a room i manage a few days ago, 17 seconds after joining they said hello, 5 seconds after saying hello, in the very same second i replied, they left
21:26:00 <clever> as-in, they said hello, and then gave up after only 5 seconds
21:26:00 <sham1> F
21:26:00 <geist> clever: bunch of c++
21:26:00 <geist> i dunno
21:27:00 <clever> a: why is this even segfaulting, b: why is such a delicate task being handled in the master process, where it can cripple the entire session?
21:28:00 <geist> because i work at google i'm supposed to know/care about this?
21:28:00 <geist> i can tell you working in the guts of chrome is one of the least interesting things i can think of doing right now
21:28:00 <zid> I'll chess you as long as you promise not to gloat when you win
21:28:00 <zid> because you play chess
21:28:00 <clever> thought you might know where i could file a ticket, i'm not familiar with all of the bug trackers google has
21:28:00 <geist> okay, actually i think there are lots more uninteresting things
21:28:00 <geist> oh, there should be some pretty easy to find public trackers for that
21:29:00 <geist> which i honestly have no idea
21:29:00 <geist> people do actually look at stuff, i can tell you that
21:29:00 <zid> sham1: https://lichess.org/tdJHxphu
21:29:00 <bslsk05> lichess.org: Correspondence casual Chess • Challenge from zid (1279?) • lichess.org
21:29:00 <clever> i'll just google it then, when i get some free time
21:30:00 <geist> but yeah save that and the version of chrome you were using, etc
21:30:00 <geist> that's probably better than 99% of the bug reports they get, and thus will probably get looked at pretty closely
21:30:00 <zid> who is this anon
21:31:00 <clever> Core was generated by `/nix/store/gy4cmipivq5gi2l7gyw7mrvxwmr4kl06-chromium-unwrapped-96.0.4664.45/lib'.
21:31:00 <zid> come on own up
21:31:00 <clever> and boom, version is also in the gist, so i dont loose it later
21:33:00 <zid> nobody going to own up?
21:33:00 <geist> also hah i just read on twitter that bill budge just retired from google
21:33:00 <geist> like omg bill budge worked here? wow
21:34:00 <sham1> God damn it
21:34:00 <sham1> Again
21:48:00 <zid> well, gg whoever that was
21:48:00 <gog> it was me :P
21:48:00 <zid> ahh ggs gog
21:48:00 <gog> i made a crucial error
21:48:00 <zid> I spotted a few of my own but thankfully you didn't :D
21:49:00 <zid> my rook was hanging for half the game
21:49:00 <gog> it was guarded
21:49:00 <gog> but maybe i missed a move :p
21:49:00 <zid> it was, then I moved something and it wasn't
21:49:00 <zid> and it stayed wasn't
21:49:00 <gog> lol
21:53:00 <geist> huh that's odd. i hooked up an old scsi disk and it let out the magic smoke
21:53:00 <geist> but then still works fine
21:53:00 <zid> filter cap?
21:53:00 <geist> i'm guessing somethingl iek that
21:53:00 <zid> those like to die, and aren't important
21:53:00 <geist> it's a fairly old trusty 36GB 10k scsi drive
21:54:00 <zid> ooh that's legit
21:54:00 <geist> which at the time would have been the shit. though it's 10k and hypothetically has shorter seek times, it still is capped at 40MB/sec, etc
21:54:00 <zid> always wanted one of the ..32GB? 10k raptors
21:54:00 <geist> yah this is some seagate thing. barracuda
21:54:00 <geist> i was sad t let out the magic smoke but... okay.
21:54:00 * gog inhales the magic smoke
21:55:00 <zid> you need some lessons from blendtec
21:55:00 <gog> i will breathe this if i want to you're not my dad
21:55:00 <zid> Neither is the guy from blendtec but you'd still call him daddy
21:55:00 <gog> :|
21:56:00 <zid> He's a total dreamboat
21:56:00 <zid> (I can't actually remember what he looks like)
21:56:00 <gog> idk i don't remember thinking he was attractive tho
21:56:00 <zid> I think he was old and average :p
21:56:00 <geist> yah i think that's exactly what i was
21:56:00 <geist> some sort of filter cap
21:57:00 <zid> do I get a prize? I won the raffle right?
21:57:00 <geist> though the burn also seems to be down inside the board just underneath it, so maybe it shorted and then burned an internal trace
21:57:00 <geist> it's just on the edge of the board so you can see the scorch all the way through it
21:57:00 <zid> "You win a toasted capacitor"
21:59:00 * gog toasts the fallen capacitor's memory
21:59:00 <zid> should I be toasting with a hurty arm, nobody told me not to
22:00:00 <gog> best to use the good arm for now
22:00:00 <zid> I am a messy drinker afterall
22:01:00 <gog> ok time to go do wife things byeee
22:01:00 <zid> make your wife do them
22:01:00 <zid> you have a solid argument that she's your wife
22:03:00 <geist> ah no its not a blown cap
22:03:00 <zid> fuck I lose
22:03:00 <geist> there's some sort of ground loop or whatnot set up if i plug this drive in at the same time as a scsi cdrom
22:03:00 <geist> both of which seem to work fine on their own, but at the same time it starts cooking something fierce in the disk
22:05:00 <geist> oh well, will use an ide cdrom
22:05:00 <geist> just wanted to start a reinstall of gentoo
22:23:00 <zid> https://preview.redd.it/ua08wgt57ia81.png?width=768&auto=webp&s=57dccdf63339a89406c860529ffaf3c8ce29a573 You should upgrade geist
22:25:00 <CompanionCube> geist: what's on the scsi disk?
22:30:00 <geist> installing to it
23:31:00 <gog> zid: she could make the counterargument that i'm her wife
23:46:00 <catern> new OS feature: Unprivileged CPU hotplug
23:46:00 <jimbzy> Gotta be quick.
23:46:00 <catern> It will pair well with PUSE (Processor in USErspace) to implement sshcpu (like sshfs but for CPUs)
23:50:00 <zid> PUSE is a spectre extension isn't it