klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
gog has quit [Quit: byee]
xenos1984 has joined #osdev
goliath has quit [Quit: SIGSEGV]
heat has joined #osdev
<heat> i am here destroyer of worlds
<heat> Ermine
<mcrod> it was I who called you
<kof673> its always double, create/destroy... :D
xal has quit []
xal has joined #osdev
k_hachig2 has joined #osdev
k_hachig has quit [Ping timeout: 260 seconds]
<bslsk05> ​twitter: <Hbomberguy> You never hear about firmware any more. What happened
raykv423 has quit [Quit: Connection closed for inactivity]
<zid> non funny response: people started using real cpus in things
<zid> things are a lot less embedded than they used to be
<heat> lets get mcrod out of a job
<heat> working is lame
heat has quit [Quit: Client closed]
k_hachig has joined #osdev
k_hachig2 has quit [Ping timeout: 256 seconds]
vdamewood has joined #osdev
<vdamewood> Hark! What wind through yonder window breaks!
* geist yawns
<kazinsal> oh shiiiiiit
<geist> heat is out of order
<kazinsal> microsoft open sourced the bizarre multitasking MS-DOS 4.0
<geist> kazinsal: wat!
<geist> wat.
<Mutabah> wat?
<bslsk05> ​github.com: MS-DOS/v4.0 at main · microsoft/MS-DOS · GitHub
<geist> i remember ms-dos 4 but i dont remember any multitaskingh bits
<geist> i forget what msdos 4s big thing was, but iirc it wsasn’t very good, and 5 replaced it pretty fast
<kazinsal> yeah, it didn't gain much traction
<kof673> dr-dos i think had some "Multi-tasking" stuff too, but have not looked
<kof673> that was later of course, don't know how far back it goes
<geist> ah there’s the 4.0-ozzie thing
<geist> that’s the multitasking version
<geist> guess it wans’t released?
<kazinsal> yeah, looks like 4.0 alone is the one that did get released
<kazinsal> the "regular" 4.0
<geist> i remember one of my dad’s work machines came with 4.0, probably one of the laptops in the late 80s
<kazinsal> was kinda hoping to see the guts of the multitasking DOS code, but more regular DOS being oss is neat
<geist> ah no was probably the houshold 386, got in 1990 iirc
<geist> since 4.0 was the dos at the time
<bslsk05> ​en.m.wikipedia.org: Timeline of DOS operating systems - Wikipedia
<kazinsal> ah, looks like the multitasking DOS got released for a few OEMs in Europe
<kazinsal> and regular DOS 4.0 was only released for OEMs, no retail/upgrade version available
<geist> holy crap that page has a ridiculous amount of detail
<kazinsal> seriously
<kazinsal> where'd my scrollbar go
<geist> there’s a guy on youtube that has a series of videos on OS/2, early windows, dos, etc that has this level of detail. wouldn’t be surprised if he didn’t fill this in
k_hachig has quit [Quit: WeeChat 4.2.2]
edr has quit [Quit: Leaving]
theruran has quit [Quit: Connection closed for inactivity]
<GreaseMonkey> i take one look at this channel and hot damn, DOS 4.0 (the interesting one) source code? yes please
<GreaseMonkey> IIRC it was released some time between 3.2 and 3.3
<GreaseMonkey> i played with it briefly i think on pcjs and honestly, i wish DOS took that route
<geist> yah
gbowne1 has quit [Quit: Leaving]
masoudd has joined #osdev
Matt|home has joined #osdev
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #osdev
bradd has quit [Read error: Connection reset by peer]
bradd has joined #osdev
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
netbsduser has joined #osdev
netbsduser has quit [Remote host closed the connection]
netbsduser has joined #osdev
vaihome has joined #osdev
\Test_User has quit [Quit: e]
masoudd has quit [Remote host closed the connection]
\Test_User has joined #osdev
vaihome- has joined #osdev
carbonfiber has quit [Quit: Connection closed for inactivity]
vaihome has quit [Ping timeout: 246 seconds]
<GreaseMonkey> ...ok, looking a bit more into it and reading the blog post, it turns out it *is* the source for the less interesting MS-DOS 4.0, but also a binary beta for the more interesting one and some BIOS source code or at least IBMBIO source code: https://cloudblogs.microsoft.com/opensource/2024/04/25/open-sourcing-ms-dos-4-0/
<bslsk05> ​cloudblogs.microsoft.com: Open sourcing MS-DOS 4.0  - Microsoft Open Source Blog
<kazinsal> yeah, not the most interesting, but still neat
<kazinsal> I'd love for them to FOSS up DOS 6.22
<kazinsal> but I'd also like ten million dollars and to be 40 pounds lighter, and only one of those three things is possible
\Test_User has quit [Quit: e]
\Test_User has joined #osdev
Nixkernal has joined #osdev
Nixkernal has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
Nixkernal has joined #osdev
synaps3 has joined #osdev
Nixkernal has quit [Read error: Connection reset by peer]
Nixkernal has joined #osdev
gog has joined #osdev
GeDaMo has joined #osdev
synaps3 has quit [Quit: Leaving]
<kazinsal> I can't find the original pressing LP of the album I want to listen to and I am a sad
<kazinsal> :(
netbsduser` has joined #osdev
netbsduser has quit [Ping timeout: 264 seconds]
<nikolapdp> :(
<GeDaMo> kazinsal: which album?
<kazinsal> Rush - Moving Pictures
<kazinsal> somewhere around here I have an original pressing but I can't find it :(
Left_Turn has joined #osdev
<nikolapdp> is geist around
<Ermine> geist: what is that os/2 channel again?
<kazinsal> it's nearing 4am here on the west coast best coast so the G-man is likely asleep
kazinsal has quit []
kazinsal has joined #osdev
kazinsal has quit [Client Quit]
kazinsal has joined #osdev
<kazinsal> thanks, irccloud
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #osdev
xvmt has quit [Remote host closed the connection]
xvmt has joined #osdev
xvmt has quit [Remote host closed the connection]
xvmt has joined #osdev
navi has joined #osdev
<netbsduser`> another import to my kernel from the various experiments i've been doing over the past few months
<netbsduser`> a great and authentic implementation of rcu classic edition, exactingly according to what's described in the patent
<netbsduser`> might have a look and see whether some of the newer patents have also expired, RCU Sleeping Edition would be a nice addition
m257 has joined #osdev
goliath has joined #osdev
theyneversleep has joined #osdev
edr has joined #osdev
\Test_User has quit [Quit: e]
\Test_User has joined #osdev
m257 has quit [Ping timeout: 250 seconds]
m257 has joined #osdev
theyneversleep has quit [Remote host closed the connection]
m257 has quit [Ping timeout: 250 seconds]
m3a has quit [Ping timeout: 256 seconds]
chiselfuse has quit [Ping timeout: 260 seconds]
chiselfuse has joined #osdev
m257 has joined #osdev
vdamewood has joined #osdev
m257 has quit [Ping timeout: 250 seconds]
m257 has joined #osdev
wereii has quit [Quit: ZNC - https://znc.in]
chiselfuse has quit [Ping timeout: 260 seconds]
chiselfuse has joined #osdev
wereii has joined #osdev
gog is now known as pog
* Ermine gives pog a piece of cheese
* pog is fascinated
* vdamewood gives pog a fishy
* pog chomp fishy
m257 has quit [Quit: Client closed]
m257 has joined #osdev
pog has quit [Ping timeout: 240 seconds]
m257 has quit [Ping timeout: 250 seconds]
op has joined #osdev
* kof673 gives kazinsal the 1995 budget version https://0x0.st/s/X-sd-3sU1CeGom8WU82bZg/XH_O.S3M (RB.S3M)
* rb listens
xenos1984 has quit [Ping timeout: 256 seconds]
xenos1984 has joined #osdev
pog has joined #osdev
pog has quit [Client Quit]
gog has joined #osdev
m257 has joined #osdev
heat has joined #osdev
<Ermine> hi heat . Was going to report that onyx master doesn't build, but actually i had to update submodules
<heat> onyx master always builds
<heat> CI baby woooooooo
<mjg> because it gets no commits
<mjg> when are you going to adopt illumos process
<heat> 2 days 13 commits
<heat> cope mjg
<mjg> is that more than illumos
<heat> yes
<mjg> then i doubt you can deliver high quality
<mjg> the smaller the project the more buraucracy you want
<mjg> bureaucracy even
<heat> burocary
<mjg> do you have path advocates for onyx yet?
<mjg> patch
m257 has quit [Ping timeout: 250 seconds]
<heat> what i say goes in and that's it
<mjg> so are you the gatekeeper?
<heat> yes
<mjg> bonwick used to be a gatekeeper for Solaris
<heat> is that how we ended up with bad filesystems? :(
<mjg> if you don't like zfs write a better one
<mjg> all talk no work this one
<Ermine> mon, ext4
<mjg> my apologiez
<zid> my mascultine ext4
<zid> when fem ext4
xenos1984 has quit [Ping timeout: 256 seconds]
heat has quit [Ping timeout: 250 seconds]
heat has joined #osdev
<heat> ext4 is transitioning
<nikolapdp> ZFS ZFS
xenos1984 has joined #osdev
troseman has joined #osdev
\Test_User has quit [Quit: e]
xFCFFDFFFFEFFFAF has joined #osdev
\Test_User has joined #osdev
xFCFFDFFFFEFFFAF has quit [Remote host closed the connection]
bauen1 has quit [Ping timeout: 246 seconds]
<geist> Ermine: https://youtu.be/rAMT187GWd4 is the one i'm thinking of
<bslsk05> ​'The Fall of OS/2' by Another Boring Topic (01:39:21)
<geist> that guy has a bunch of vids for PC development and windows
voidah has joined #osdev
xFCFFDFFFFEFFFAF has joined #osdev
voidah has quit [Ping timeout: 268 seconds]
<wantyapps> say, is there any implemented version of math.h I can view? I didn't find the source code
<wantyapps> probably didn't search enough :p
<wantyapps> nvm found it
zy has joined #osdev
gbowne1 has joined #osdev
voidah has joined #osdev
heat57 has joined #osdev
carbonfiber has joined #osdev
heat has quit [Ping timeout: 250 seconds]
<childlikempress> core-math
Mooncairn has joined #osdev
<nikolapdp> what do you mean childlikempress
<geist> yah i'd look in BSDs for that
<childlikempress> core-math is an 'implemented version of math.h'
<childlikempress> specifically it's the best one :p
<geist> they have a nice math that you can easily grab and plonk in your stuff, since aint nobody got time to write lib math
<nikolapdp> oh so it is
<childlikempress> bsds, musl, glibc, macos, openlibm, all are just msun
<geist> childlikempress: core-math? do you have a link?
<geist> yah
<bslsk05> ​core-math.gitlabpages.inria.fr: The CORE-MATH project
<nikolapdp> lol beat ya
<childlikempress> race conditions😔
<geist> noice.
<childlikempress> this really says a lot about our society
<geist> might have to look at it
<geist> it's MIT licensed too, yay
<nikolapdp> geist: one question about your toolchains script
<geist> heh betcha it doesn't work for VAX floating point
<nikolapdp> can it do custom triples
<geist> nikolapdp: if you want to try you can hack doit to pick it out, or add another switch
<geist> but no, not without tweaking it
<nikolapdp> might just do it
<nikolapdp> it's really neat, i've got to say
<geist> grenerally i twaek something like https://github.com/travisg/toolchains/blob/master/doit#L234
<bslsk05> ​github.com: toolchains/doit at master · travisg/toolchains · GitHub
<geist> but seems that having some sort of -T switch or something to override the triple would be a nice addition
<geist> btw if it works for you i have a ton of prebuilts: https://newos.org/toolchains/
<bslsk05> ​newos.org: Index of /toolchains
<heat57> yeah but generally it's not just as easy
<heat57> i have some crazy incantation i use for my gcc and binutils configure
<geist> yah good chance a custom triple wont work
<heat57> wrt the system root or the lack thereof
<geist> thing though is the doit script here is sysrootless, it doesn't build anything that needs a sysroot
<geist> so it *might* work with more or less any triple
<geist> but probably wont for reasons
<nikolapdp> seems like it should work with a prebuilt, but if i get it to work properly with a custom triple, i'd send you a patch
op has quit [Remote host closed the connection]
<heat57> yeah but do you pass the stuff to convince sysroot-full targets you don't need one?
<nikolapdp> eh i don't know lol
<heat57> btw geist magenta doesn't build anymore!!!!
<geist> 100% not surprised. what fails?
<geist> prebuilts dont download?
<heat57> everything :)
<nikolapdp> what's a magent
<heat57> oh this is pre-prebuilts
<nikolapdp> magenta
<heat57> still works with the lk build system
<heat57> magenta was zircon
<nikolapdp> oh they renamed it
<heat57> yes
<geist> actually surprised you can find the repo, or is this an old synced repo?
<nikolapdp> lol why, not like it was a very public project or something
<heat57> go to fuchsia.git and you'll find the initial magenta commit
<geist> oh i see, yeah pulled into fuchsia.git. vs the proper magenta repo, which i'm sure is not publically available
<heat57> yeah i just see an initial commit thingy
<heat57> everything flattened i imagine
<geist> heat57: well, also you might want to go to the zircon repo which predates the fuchsia.git one
<geist> i think when they moved to a flattened repo someone played back the zircon.git repo into it
<heat57> whoever did the merge kept the history
<bslsk05> ​fuchsia.googlesource.com: 53b9e1c8de8446a88409d17c4aed70be33349378 - fuchsia - Git at Google
<bslsk05> ​fuchsia.googlesource.com: zircon - Git at Google
<heat57> this predates the zircon merge IIRC
<geist> it does, but only because it played back the zircon.git history into it
<heat57> yep
<geist> but it's possible that didn't get replayed precisely right
<geist> i'd check out the zircon repo
<heat57> anyway: the gn build simply doesn't work anymore, the LK makefile seems to have a $(SPACE) variable that was broken in some GNU make update probably
<geist> there was a magenta repo prior to that, but it got killed
<geist> gn could be because it needs a newer or older version of gn than you have
<geist> the space thing is surprising though
<heat57> then toolchain problems galore, I think i'll try an era-appropriate (5.0? 6.0?) -elf toolchain that doesn't have default PIE and default ssp and ld bfd default etc
<geist> there was a toolchain repo at the time where we were building our own gcc from
<bslsk05> ​github.com: Fix incompatibility with Make 4.3. · littlekernel/lk@77f5dac · GitHub
<heat57> found it
<nikolapdp> heat are you building fuchsia for fun
<heat57> magenta yes
<nikolapdp> lol
<geist> https://fuchsia.googlesource.com/third_party/gcc_none_toolchains/ i think, which is a fork of my travisg/toolchain script
<bslsk05> ​fuchsia.googlesource.com: third_party/gcc_none_toolchains - Git at Google
<nikolapdp> well good luck
<nikolapdp> wonder what you can even do with it
<heat57> early magenta is a trivial build
<heat57> before the gn merge and needing all the google tooling
<heat57> and taking 2 hrs to fucking build
<nikolapdp> geist: another interesting addition could be passing custom arguments to the configure script
<nikolapdp> for your toolchains
<geist> extracting zircon/magenta out of fuchsia dn building new things on top of it would be useful. it's somewhat specifically built to be system agnostic
<geist> trouble is there's a fair amount of work to extract it back out of the build system, but it's pretty surmountable
<geist> toolchain wise basically a tip of tree clang/llvm is all you generally need to build it
<heat57> yeah but early magenta is already out of the build system
<geist> yeah
<heat57> and it's delightfully monolithic AND still lkuser-ish
<geist> it wasn't until 2018 or so that it eventually got fully integrated
<geist> the make stuff in zircon got initially replaced with it's own GN-based build system (different form the overall one) and then integrated into the overall build system
<geist> which IMO was actually worse design than the zircon specific gn-based one
<geist> now internally everyone basically agrees that the GN buidl system is not good and it's a mess, and there's some push to replace with bazel
<heat57> build systems are bad
<geist> not that make would have scaled to deal with what we ended up building with GN, but GN has it's own issues
<heat57> for the kernel? it can scale fine
<geist> mostly in its works-as-designed inflexibility in a lot of axis that caused us to build a lot of really wonky abstractions on top of it
<heat57> yeah
<geist> agreed re:kernel. but one of the things that was basucally a full-stop-no-exceptions rule with folks developing build systems around work is there shall only be one
<geist> ie, no recursive building of multiple build systems. which i think is very silly, but thats what dogma gets you
<heat57> yeah
<geist> ie, all build systems must always be single instance
<geist> tis why, for example, when we import a rust or any third party thing into fuchsia the build system for that thing must be rewritten as gn
<geist> even rust. no cargo, etc etc
<heat57> yeah
<nikolar> getting away from cargo might not be the worse decision :P
<geist> so now of course we have thousand and thousands of .gn projects that is going to take the heat death of the universe to replace
<heat57> tbf i'm not sure how one can easily deal with recursive build systems and remaining build-systemy
<heat57> as in having proper source deps etc
<heat57> the answer is probably: tough shit, you can't
<geist> you dont, you lose the flexibility of source level deps, but you get modularity
<geist> it's how all large OS projects i've ever seen work
<Griwes> I mean you deal with it Very Carefully
<geist> like, debian doesn't build all of linux including the kernel, with one big ass make file
<geist> it's not feasible
<geist> or OSX, or windows, etc
<Griwes> my current OS iteration barely has any components and the only sane way to build them that I found was to be very explicitly recursive from the top
<Griwes> well, at least with currently available build systems
<Griwes> I've been pondering one that doesn't have global compilers and whatnot, but rather objects representing toolchains that you pass to build targets to define them, but it has been a while since I've touched that
<geist> yah for the lkuser stuff that i need to piddle with more i definitely am doing it as a recursive, at least in as much as external things are brought in
<Griwes> also I'm rather happy with how the component definitions ended up looking: https://github.com/griwes/reaveros/blob/main/libraries/archive/component.cmake
<bslsk05> ​github.com: reaveros/libraries/archive/component.cmake at main · griwes/reaveros · GitHub
<heat57> dang you picked the C++-iest of build systems
<Griwes> yes
<heat57> can you invoke external projects (with other build systems) from cmake?
<Griwes> because I knew how to deal with ExternalProject and knew I can make the necessary magic work
<Griwes> lol
<Griwes> literally was typing the answer to that question while you were typing it
<heat57> :))
<nikolar> RACE CONDITION
<heat57> gn gets very sad if you ever invoke something external
<bslsk05> ​github.com: reaveros/toolchain/llvm.cmake at main · griwes/reaveros · GitHub
<Griwes> which, even though it has cmake, I build as a subproject
<Griwes> (I also build it with cmake that I build earlier in the process :P)
<zid> heat57 what else can I wrt, other than ..plt
<zid> can I wrt ..urmum
<nikolar> sick burn
<heat57> what
Nixkernal has quit [Ping timeout: 255 seconds]
<geist> heat57: yeah the 'no externals' part of GN is one of the hard-codedness
<geist> gn is very opinionated, and it was built to solve one thing: building chrome
<nikolar> makes sense
<heat57> you can get around it if you use PYTHON!
<geist> and it explicitly makes it hard to do certain things, because those were things it was designed to not let you do
<Griwes> heat57, https://github.com/griwes/reaveros/blob/main/cmake/target_functions.cmake and this is how I make creating internal targets and various aggregate targets easy; there's some almost-forbidden techniques in there if you want to learn those :'D
<bslsk05> ​github.com: reaveros/cmake/target_functions.cmake at main · griwes/reaveros · GitHub
<heat57> i think what i'll eventually end up doing might be to get some package manager to build individual packages + some cheap makefile to automate that for me
<heat57> Griwes: yeah i know 0 cmake :^)
<Griwes> that's _kinda_ what this entire cmake DSL is
<heat57> apart from the little i needed to hack on LLVM
<nikolapdp> package manager for what heat57
<heat57> for packages
<Griwes> it's likely that it'll evolve into a proper package manager _eventually_
<nikolapdp> are we talking onyx userspace or what
<heat57> userspace and kernel
Nixkernal has joined #osdev
<nikolar> what packages would you have for the kernel lol
<heat57> say if i adopted pacman, i'd use makepkg + pacman to build and install the kernel
<heat57> "kernel"
<Griwes> nikolar, libraries for one ;p
<nikolar> ah right
<heat57> and maybe separate modules
<zid> wtf, I wrote the yasm manual heat
<zid> check the first page
<Griwes> I have libraries that I share between userspace and kernel space
* zid adds to CV
<heat57> yeah i don't do that
<nikolar> zid you were so drunk you didn't even realise
<heat57> i share some headers
<Griwes> and it's fairly easy for me to define a library to be built for both
<heat57> oh yeah, headers would be a separate package
<Griwes> well, "built", it's mostly installing headers
<Griwes> + .a that contains a single .o that defines memcpy & friends lol
<heat57> geist: hmm do osx and windows have packages internally too?
<heat57> cuz they don't seem to expose much of those details externally
<heat57> i guess i've seen some software components in windows update logs but its never "updating zlib.dll"
Starfoxxes has quit [Ping timeout: 255 seconds]
Starfoxxes has joined #osdev
Arthuria has joined #osdev
zy has quit [Ping timeout: 245 seconds]
Arthuria has quit [Ping timeout: 245 seconds]
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
Arthuria has joined #osdev
zy has joined #osdev
xFCFFDFFFFEFFFAF has quit [Quit: Joined Libera]
zy has quit [Quit: leaving]
xFCFFDFFFFEFFFAF has joined #osdev
<nikolapdp> geist, how do you prefer to receive patchen
<geist> well, github pulls work okay. i dont really like the review thing, but i dont really have any better
<geist> i suppose a mailed patch to my email address would work too
<nikolapdp> yeah i can do that
<nikolapdp> i've added the custom triplet thing
<nikolapdp> i'll try to add the custom configure options
<geist> oh i see to the toolchain thing, eyah
<geist> SGTM
<zid> how do you do global vars in pie
<nikolapdp> you fix them relative to the start of the program?
<zid> got entry, wrt ..got?
<mjg> watcha patchin'
<mjg> lk?
<netbsduser`> i have to admit to never having tried gn
<nikolapdp> geist's toolchains script
<nikolapdp> mjg^
<netbsduser`> i remember dealing with gyp when maintaining chromium for solaris for a short while
<nikolapdp> zid: why would you touch got
<zid> pie
<zid> global var
<zid> I mean, I'd like it to not do the relocation stuff
<nikolapdp> yeah, relative offset to the %rip works
<nikolapdp> no need for gop
<nikolapdp> *got
<zid> yea makes sense you don't *need* it
<zid> needs a relocation still
<nikolapdp> what are you doing so that makes you care about relocations
<zid> linking
<nikolapdp> what, writing a linker?
<zid> no, a global var
<zid> I just wanted to know how they worked
<zid> "you get a pcrel relocation for them"
<nikolapdp> yeah, end then the linker figures out how far it is from the relocation and fills it in
<zid> and presumably symbol visibility and stuff is involved, cus afaik gcc doesn't spit out symbols for them
<nikolapdp> once it's coalesced the sections
<zid> so you might need to unhidden it for certain linkers
<nikolapdp> why would symbols work differently
<zid> hmm wasn't there a way to make objdump print symbol names in relocations
<zid> or do I need compiler support for that, -R didn't do it off this assembly file at least
<nikolapdp> doesn't it do that automatically
<nikolapdp> with juts disassembly
<zid> oh r showed it
<zid> R did not
<zid> 0: 48 8d 35 00 00 00 00 lea rsi,[rip+0x0] # 0x7
<nikolapdp> interesting
<zid> 0: 48 8d 35 00 00 00 00 lea rsi,[rip+0x0] # 0x7
<zid> 3: R_X86_64_PC32 a-0x4
<zid> latter is -r
<nikolapdp> yeah cool
<Ermine> geist: thank you for video
<zid> oh it's -shared that causes the errors
<zid> that was I trying to debug
<nikolapdp> lol i guess that of all things, that would mess with relocations, yeah
<zid> gotpc is the classical solution here I think, but I think you can actually
<zid> double link
<nikolapdp> what interesting gcc configure options could i try to test out the script
<Ermine> finally, cleaned up my desktop
<Ermine> I need to de-dust my pc as well
<zid> yea wrt ..gotpc fixes it
<nikolapdp> zid: any interesting gcc configure flags?
<zid> --default-pie
<nikolapdp> give me another one
<zid> --with-sysroot=/home/heat
<nikolapdp> lol that'D
<nikolapdp> D
<nikolapdp> lol that'll do, thanks
<nikolapdp> lol thanks zid: configure: error: unrecognized option: `--default-pie'
<zid> with?
<heat57> --with-default-pie I think
<zid> worked for your test though right? :P
<zid> confirmed you could pass configure options
<nikolapdp> lol true ture
<nikolapdp> yup, building with --with-default-pie
<nikolapdp> *it's building
<zid> My pointer is off by 8
<zid> idk why
<zid> I've had this bug/issue before though
<zid> where it was off by 4 in 32bit
<nikolapdp> what pointer
<zid> relocation
<zid> me and.. gog? were messing with something similar before
<gog> hi
<zid> and trying to decode the relocations, but for some reason they were stored -8 instead of -4 that the spec and all the tools claimed, or something
<zid> does that ring a bell gog
PublicWiFi has quit [Ping timeout: 256 seconds]
<nikolapdp> hello gog
voidah has quit [Ping timeout: 245 seconds]
<gog> i only have relative and jump slot
<gog> i think i'm using large model and that might be an issue i need to address because i don't need
<clever> yeah, ive looked into that before, and the other models cause gcc to generate things like pc relative jumps with only a 24bit? offset
<zid> does that ring a bell gog
<zid> or was it someone else
<clever> the root problem, is that only the linker knows the actual size of the offset
<heat57> i feel like you're running without relocating your code
<clever> and the linker cant change the opcodes, because gcc/as baked some pc-relative offsets within the generated code
<heat57> but i dunno what you're doing exactly
<gog> zid: i don't think it was me
<zid> kk
<clever> i think this is one area LTO can solve, but only for build-time links
<clever> any dynamic linking is then left up for later, and i think you generally leave the full pointer width in the table?
<zid> maybe it was froggey
<zid> from a quick grep
<zid> but doesn't feel right
<nikolapdp> can you even disassemble the lto objects
<nikolapdp> aren't they supposed to contain just the ir
<zid> they're fat
<zid> and contain both
<zid> you need to use --with-lto=thin-lto or some crap to not have it do that
<heat57> not by default
<heat57> -ffat-lto-objects
<zid> oh did they swap it most of my lto docs were from 6.0 tbh
<clever> nikolapdp: i believe it contains both the normal .o contents (so a non lto link can proceed) and also the ir (so gcc can fuse the units together, re-optimize, and re-generate asm)
<heat57> you need to ask for fat LTO by default i'm pretty sure
<heat57> s/by default//
<clever> another trick i found a while back that is handy, `objdump -dr foo.{o,elf}`
<bslsk05> ​gcc.gnu.org: LTO Overview (GNU Compiler Collection (GCC) Internals)
<clever> the -r will insert relocations inline as it disassembles
<clever> 206: 80 90 00 00 bl 206 <platform_early_init+0x206>
<clever> 206: R_VC4_PCREL27_MUL2 setup_pllh
<zid> the gcc 6 version of this or whatever says "We only support fat" or something :P
<clever> so it generates things like this
<clever> here, we have a pc-relative 27bit offset, and the mul2 just means bit0 of the offset doesnt exist, it must be 0
<zid> GIMPLE bytecode could also be saved alongside final object code if the -ffat-lto-objects option is passed, or if no plugin support is detected for ar and nm when GCC is configured
<zid> *or if no plugin support is detected*
<zid> that might be relevent to some of my cases where it defaulted fat
<clever> because the original as pass didnt fill in the addr, the offset is 0, and the bl is pointing to itself
<clever> but with -r added, you can see what symbol it intended to call
<mjg> wooo i'm telneting somewhere
<mjg> talk shit all you want, telnet banner is great
<nikolapdp> you can enable ssh banner too if you want in sshd_config
<clever> i was curious, so i checked some mcmodel things: https://gist.github.com/cleverca22/52af74860420fb71d5648eb52cdf7e5c
<bslsk05> ​gist.github.com: gist:52af74860420fb71d5648eb52cdf7e5c · GitHub
<clever> with medium and small, it generates a single jump via the PLT? and i assume there is a restriction on how far the PLT can be from this opcode
<clever> but with large, it generates a mess of 8 opcodes, and 2 relocations
<mjg> nikolapdp: i know, who gives af
<mjg> nikolapdp: you may be too genz to get it
<zid> 2 gigglebytes on x86
<nikolapdp> lol, i am saying, you can do the same thing
<nikolapdp> giggl
<zid> cus all the relocs are 64_32_PCGOTREL or whatever
<clever> i feel like just using small or medium 99% of the time, is the right answer
<zid> large is the one that turns that limit off, afaik, not sure if it's.. tested, though? :p
<zid> it's apparently bad to use a large model on modern cpus anyway, heat was complaining about it
<zid> that big relocations are slower
<clever> small would generate smaller code, and in most cases, your code isnt large enough to ever need more?
<zid> if you have a >2GB text section I have bad news for you
<geist> on x86-64 at least it generates a ton of movabs to get the full address range
<geist> and then most calls are indirect
<clever> yep, i can see 2 mobabs's in the gist above
<clever> i think small and medium are using a jmpq variant that is pc-relative, and given the 2gig limit, signed 32bit offset?
<geist> yep
<geist> arm64 has somethng like a 28 bit range? I forget
<clever> so it could maybe handle a 4gig .text, but then a function at the ends can only jump to the middle, and you would need some trampolines, lol
<geist> but it an riscv can in two instructions compute a PC relative within 4GB
<clever> and making it a 2gig limit just ensures one end can reach the other end in a single leap!
<clever> but at all times, half of your pc-relative jump range is out of bounds
<bslsk05> ​gist.github.com: gist:52af74860420fb71d5648eb52cdf7e5c · GitHub
<clever> repeated the test on aarch64, arm32, and thumb, with the default models
<clever> loks like its a 26bit offset with aarch64, and arm32/thumb dont clearly specify the bit width
<clever> arm also seems to be generating more prologue/epilogue then x86 did, the functions are a lot fatter overall
<clever> but that might be differences in how gcc was configured, on x86 i used a linux hosted gcc, while on arm i used a -none one
<clever> i saw something on the osdev wiki, about not using the hosted gcc for baremetal kernels?
xFCFFDFFFFEFFFAF has quit [Read error: Connection reset by peer]
<kof673> i'm lost. build/host/target. build is what system you are building the compiler on, host is where the compiler runs surely? target is what it will generate code for
<zid> means you need to pack your kernel build with a bunch of bizzare options to override every distro's random defaults, and the libgcc won't work after you do that
<zid> -no-pie -mno-redzone -zmax-pagesize=4096 blah blah blah
<zid> and if a new option gets added your builds break
<nikolapdp> that's why we have cross compilers
<nikolapdp> and after geist merges my changes, i'd recommend his script to build them :)
<zid> can I still use crossdev
<kof673> ^ and second ^ on x86 i used a linux hosted gcc, while on arm i used a -none one <<< that sounds like *target* to me, which *may* be the same as "host"
<nikolapdp> sure zid, only you are allowed
<zid> cool
<clever> kof673: by hosted, i mean that gcc expects the target to have a linux kernel
<zid> oh I should annoy my animals
<kof673> that makes sense "by host i mean target" :D
<kof673> not being sarcastic, makes sense
<clever> and things like what zid said likely also apply
<clever> i can see how redzone is fine in userland, but bad in kernel
<clever> and a gcc targetting linux userland could have redzone enabled by default
<nikolar> -mno-redzone
<nikolar> ez
<zid> nikolapdp: wanna watch me annoy the shit out of some animals?
rpnx_ has joined #osdev
Left_Turn has quit [Read error: Connection reset by peer]
<clever> kof673: also, there is the canadian cross! https://wiki.osdev.org/Canadian_Cross
<bslsk05> ​wiki.osdev.org: GCC Canadian Cross - OSDev Wiki
<nikolapdp> sure zid
<kof673> i gave kazin his rush s3m, that is my canadian quota for the year
<GreaseMonkey> tried playing around with protected mode in FreeDOS 1.3, turns out in the "seriously please don't load any drivers" mode it seems like it sets up a warm reboot handler for whenever you screw up and triple-fault the CPU
<GreaseMonkey> i have mangled so many GDTs and caused so many triple faults... and haven't had to properly reboot the machine once
navi has quit [Quit: WeeChat 4.2.1]
<mjg> i'm installing debian 3.0 (release 2005) in a vm, the installer is clunky af
<mjg> worse than i remembered
<heat57> why would you
<heat57> ever
<heat57> install debian
<mjg> just wanna check something
<mjg> it appears it hung doing mkfs though
<mjg> i'm gonna try SLACKWARE instead
rpnx_ has quit [Ping timeout: 252 seconds]
<heat57> does modern mkfs use O_DIRECT?
<mcrod> i have learned not to try and install debian
<heat57> i was thinking about blockers on an onyx installation process and if mkfs uses the page cache it might be one of the blockers to add proper reclamation
<heat57> i was reading more about the ext4 journal just now
<mjg> mofo took several minutes but got through it
<heat57> really just stupid they didn't shard the journal per-block-group
<mjg> unpacking debs is rolling fine, so i don't know what's that about
<heat57> an fsync to a single file needs to commit the transaction FOR THE WHOLE DISK
<heat57> inzane
<mjg> oh yeah? do better
<heat57> i believe the xfs journal is per-AG
<clever> heat57: another factor, is that ext4 and zfs, handle the journal in vastly different ways
<nikolapdp> true
<clever> with ext4, i believe the journal is a sort of write ahead log, so you write important metadata to the journal, as a block#+contents pair
<clever> and then overwrite the metadata in the proper location
<clever> and if interrupted, the next boot can just copy it from the journal to finish the job
<clever> but for zfs, the journal is instead a log of vfs actions, write/truncate/delete
<nikolapdp> yeah because you can't really know everything in advance
<nikolapdp> so you write the commands instead of the raw blocks
<clever> yeah, its faster to log the commands, because it can be costly to know what the metadata should be
<nikolapdp> yeah
<clever> but, zfs can also reuse the backing data blocks, between the journal and the final data
<mjg> lmao slackware is even worse
<clever> so the data itself isnt copied, only the metadata
<clever> also, each dataset in zfs (basically a filesystem) has its own journal
<mjg> you have to run cfdisk by hand before you run the installer
<nikolapdp> yeah zfs is pretty neat
<nikolapdp> but i think you mistook xfs for zfs clever, lolo
<nikolapdp> s/lolo/lol
<clever> yep, i run zfs on nearly all of my machines
<nikolapdp> i do too
<clever> i'm not familiar with how xfs handles its journals
<mjg> clever: on linux tho?
<nikolapdp> ye
<clever> mjg: yeah, all of my recent linux installs have zfs rootfs
<mjg> wut
<mjg> what's your take on btrfs
<nikolapdp> i don't care
<mjg> anyhow, the slackware installer printed that an error message from cat
<mjg> and proceeed to claim the install is complete
<mjg> gg
<clever> mjg: i tried using it before zfs, deleting a large pile of temp files took 2 hours and then btrfs timed out and went read-only, lol
<mjg> fucking WEBDEV
<clever> i later discovered, a firmware flaw in my sata ssd's
<mjg> clever: :p
<mjg> when was that
<mjg> oh so it's not even its fault
<clever> under certain write patterns, the ssd just locks up solid
<nikolapdp> lol i used an hdd with btrfs once, got corrupted literally the first time i tried doing something
<clever> but i only discovered that flaw years later
<mjg> zfs used to be notorious for getting into a spot where you can unlink a file
<mjg> because there is not enough free space
<nikolar> if you're worried about that, set a quote
<nikolar> quota
<clever> i think snapshots make that worse, but changing the slop space helps
<clever> [root@amd-nixos:~]# cat /sys/module/zfs/parameters/spa_slop_shift
<clever> 5
<mjg> nikolar: lul
<mjg> this is a problem which should NEVER happen
<clever> this reserves some chunk of the disk, like 30-40gig on some of my pools
<mjg> and for some years now no longer does
<clever> so zfs can write even when "full"
<clever> changing that number can give you a ton more space
<mjg> boils down to making sure the reserve is big enough to store that you unliked some shit
<nikolar> yeah
<nikolar> but not juts that
<nikolar> you also need to free the snapshots that have that deleted thing
<clever> with slop at 4, i have 0 bytes free, 5 gives 3.9gig free, and 6 gives 11gig free
m3a has joined #osdev
<clever> nikolar: ive never had problems deleting things when full, but due to snapshots, deleting things when full does not actually free up space, so writes cant proceed
<nikolapdp> yeah that's what i said
<clever> also, running the free space down that low, has other more costly downsides, it fragments the free space something nasty