Search logs:

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=21&m=11&d=21

Sunday, 21 November 2021

00:12:00 <geist> ah well ifyoure reading the logs the other thing you probably have to piddle with is `-mcmodel=medany` if/when you fiddle with riscv64
00:12:00 <geist> i had to tweak my gcc compile to include that as a multilib
00:12:00 <geist> otherwise i think the default multilib stuff on gcc already gets one
00:13:00 <geist> https://www.irccloud.com/pastebin/r3JBzL2y/
00:13:00 <bslsk05> ​IRCCloud pastebin | Raw link: https://irccloud.com/pastebin/raw/r3JBzL2y
00:13:00 <geist> etc. the only addition in my scripts is the medany stuff for rv64
02:23:00 <heat> geist, I disabled multilib because it was giving me grief with rv32 multilibs and not having a 32-bit sysroot
02:24:00 <heat> that was probably not a good idea now that I think of it lol
04:08:00 <zid> baba is baba and move and you and hello
04:09:00 * vdamewood pushes you
04:09:00 <heat> zid has gone crazy
04:10:00 <kazinsal> BABA is PISSED and HAS KNIFE
04:10:00 <zid> knife is defeat
04:10:00 <vdamewood> rock is you baba is push
04:11:00 <heat> BABA owns LIBERALS with FACTS and LOGIC
04:13:00 <zid> stop making up words
04:15:00 <heat> y'know when I said I was going to "port my OS to riscv" I really didn't mean fiddle with multilib and re-think parts of my toolchains
05:47:00 <heat> i've accidentally erased a few hours of work
05:47:00 <heat> fml
05:52:00 * vdamewood fucks heat's life.
05:53:00 <vdamewood> Reminds me of a time when I ran rm -Rf * thinking I was in /dev/build/myproject when I was really in /dev/src/myproject
05:54:00 <heat> i've done that too
05:54:00 <heat> curiously I only do shit like this when working in my toolchains
05:54:00 <vdamewood> Fortunately, the * glob didn't match .git
07:05:00 <geist> heat: sadly rethinking toolchains is frequently a lot of it
07:09:00 <heat> geist: something I meant to tell you a few horus ago: you should patch your toolchains to build libgcc as pic
07:09:00 <heat> that lets you avoid the mcmodel multilibs
07:09:00 <geist> oh yeah?
07:09:00 <geist> hmm, not so sure though. medany is a code gen thing
07:09:00 <geist> as in does it assume that pointers are signed 32bit, etc
07:10:00 <heat> mcmodel=kernel is also code gen no?
07:10:00 <geist> unless also building as pic also effectively disables that
07:10:00 <geist> i dont think so on riscv. the only real one is medlow (default) vs medany
07:10:00 <geist> and it doesn't matter on 32bit because all pointers are within +/-2GB of something there
07:11:00 <heat> well shouldn't pic just assume pointers can be anywhere?
07:11:00 <geist> possiblky it effectively forces medany
07:11:00 <heat> like a medany but even more position independent
07:12:00 <heat> i compile the x86_64 and riscv64 libgcc/crtstuff as PIC and everything works for x86_64 (and probably for riscv unless relocations are very very weird in riscv)
07:23:00 <geist> well that may be true, but be careful about applying one arch to the other
07:23:00 <geist> that may commonly be the case, but when it comes to stuff like memory models and codegen things can be quite different between arches
07:23:00 <geist> especially relocations
07:24:00 <heat> i'm assuming that if something is horribly wrong then linker goes boom
07:24:00 <geist> oh absolutely
07:25:00 <geist> where the medany stuff comes into play is explicitly linking things to run outside of the 2GB window
07:25:00 <geist> ie, high 64bit
07:25:00 <geist> then boom happens. hence why you never see it with riscv32
07:26:00 <heat> doesn't medlow also cover high 64bit?
07:26:00 <heat> the -2GB region
07:26:00 <geist> i dont know
07:26:00 <heat> The program and its statically defined symbols must lie within a single 2 GiB address range and must lie between absolute addresses -2 GiB and +2 GiB.
07:26:00 <geist> there you go
07:26:00 <heat> sounds like a mcmodel=small + mcmodel=kernel
07:27:00 <geist> yah. so the main issue iirc is that on sifive hardware the starting physical addresses are 0x8000.0000+
07:27:00 <geist> so. if you boot on a 64bit machine your'e already in medany territory
07:28:00 <heat> shouldn't be an issue if you run in virtual memory right?
07:29:00 <geist> right, but LK can run in all of the modes. with and without virtual memory
07:29:00 <heat> ah
07:29:00 <geist> and then with VM it runs not within -2GB, but it could be
07:29:00 <geist> there's a build option for machine mode 64bit (no mmu) so in that case it has to be linked at the final address, which can be >2GB, so medany
07:29:00 <geist> that was actually what forced it, sicne that's what i had working first
07:30:00 <geist> i added the mmu code and virtual memory mode (supervisor 64bit) later
07:33:00 <heat> what's the default march?
07:35:00 <heat> --print-multi-os-directory gives me ../lib/lp64d with no arguments which is weird unless riscv doesn't put stuff in /lib but rather /lib/lp64 and /lib/lp64d
07:35:00 <geist> that's usually relative to their root
07:35:00 <heat> also applies to the sysroot I think
07:35:00 <geist> dunno what default march is, i'd highly suggest fully specifying it
07:35:00 <geist> also the mabi
10:09:00 <geist> hah once again struck by the 'AMD treats G bit as MBZ on inner page tables' problem
10:10:00 <geist> actually just debugged that this core (3950x) doesn't seem to follow their manual precisely
10:10:00 <geist> the manual seems tos tate that on x86-64 4 level paging the G bit (bit 8) is MBZ *only* on the top level PML4 entry
10:10:00 <kazinsal> oh that's annoying
10:10:00 <geist> but it seems to also fire with a PDP level
10:11:00 <geist> perhaps i haven't enabled 1GB page tables somewhere else so it now fires there?
10:11:00 <geist> one way of reading it is their logic is if the page table entry cannot be interpreted as a terminal entry then the G bit MBZ
10:12:00 <geist> and in all of the variants of page tables (2 3 or 4 level) only the PML4 entries fit that with usual 4 level paging + 1GB pages enabled
10:15:00 <geist> though also oddly i was only able to see this on virtualbox. so i'm not entirely sure what's going on there
10:15:00 <geist> was getting a weird page table with a 0 error code, but then clearing the G bit made it go away. so i'm not entirely sure what i fixed
10:19:00 <zid> MBZ?
10:21:00 <zid> oh must be zero
10:23:00 <zid> amd's manual for the page tables is weird
10:24:00 <zid> double diagrams showing both the pml4e and pdpe, showing that the pml4e must be zero, but pdpe's G bit works
10:24:00 <zid> and worse for things like 4k
10:28:00 <zid> Intel's single stacked diagram <3
10:28:00 <zid> Okay so intel says Ign. and amd says must be zero, that seems like an easy bug to accidentally happen
11:03:00 <geist> zid: yeah and i know about it because we bumped into it on zircon
11:03:00 <geist> but i never back ported that fix to LK, so i knew immediately what was wrong
11:04:00 <geist> but actually was reading the docs to verify what i remember was right, and it's a little funny, but makes some sense
18:11:00 <heat> 8am to 6pm is a based sleeping schedule
18:13:00 <sham1> If only I could have a sleep schedule of 1 AM to 10 AM
18:14:00 <sham1> That seems to be my natural sleep cycle. But alas, it's not possible because work starts at 8 and I also have courses sometimes at 8. It's crappy
18:15:00 <heat> that sounds
18:15:00 <heat> boring af
18:15:00 <heat> funnily enough I mostly seem to get into these "work til 7am" moods when doing toolchain work
18:17:00 <heat> probably because I can't get bored writing code
18:17:00 <sham1> Technically I could start my work at 9 but that'd mean that I would only be able to leave an hour later. Although Tuesdays are especially brutal since I have to wake up at 7 just so I can prepare myself mentally to cycle through the late autumn darkness to the campus to work
18:36:00 <zid> heat: about the same as me atm
20:41:00 <mjg> https://old.reddit.com/r/starterpacks/comments/qwn4xb/linux_user_starterpack/
20:41:00 <bslsk05> ​old.reddit.com: Linux user starterpack : starterpacks
20:41:00 <mjg> > There are lots of operating systems that would be usable. The BSDs, Plan9, Haiku... maybe even something like SerenityOS or ToaruOS if you're feeling adventurous :D
20:41:00 <mjg> did niche systems become mainsteam?
20:41:00 <mjg> i mean knowledge about their existence
20:42:00 <moon-child> tbf I feel like there's a more prominent contingency of openbsd users on thinkpads than linux users
20:43:00 <mjg> i can tell you red hat was all thinkpads and that probably accounts for majority of linux on a laptop
20:43:00 <mjg> ;)
20:43:00 <mjg> [not a serious comment]
21:00:00 <geist> indeed, seems that most of the folks at my work that are using linux (you have an option of linux, mac, or chromebook) go for the thinkpad options
21:01:00 <geist> i'm not a tremendous thinkpad fan but if i had to have a linux laptop, which i generally dont want to futz with if i can avoid it, a thinkpad is probably the most solid choice
22:40:00 <immibis> off-topic but several people will certainly find it amusing:
22:40:00 <immibis> "Instead of a Turing Machine that determines whether or not another Turing Machine will halt we construct a DFA lexical analyzer that recognizes the single literal string of “the”."
22:47:00 <immibis> this is how to solve the halting problem. (1) write a program that recognizes the word "the". (2) adapt it so instead of recognizing the word "the", it recognizes Turing machines that halt.
23:14:00 <geist> these are words i recognize
23:44:00 <Mutabah> immibis: 2. draw the rest of the owl :)