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

Thursday, 11 July 2024

01:06:00 <heat> wow i found the bug, my radix tree copy was slightly borked
01:06:00 <heat> literal one line patch
01:09:00 * vdamewood adds a semicolon to heat's code
01:34:00 * mjg adds typos
01:36:00 <heat> aww sweet i can compile GNU hello now
01:38:00 <kof673> https://github.com/reinderien/mimic it used to be monster-in-a-box logo :)
01:38:00 <bslsk05> ​reinderien/mimic - [ab]using Unicode to create tragedy (102 forks/3743 stargazers/MIT)
01:53:00 <adder> heat?
01:54:00 <heat> adder!
01:54:00 <adder> paging then long?
01:54:00 <heat> sure
01:54:00 <heat> mjg, https://gist.github.com/heatd/d1df4c679d1326a5847401d0e771cef9 make -j4 of gnu hello
01:54:00 <bslsk05> ​gist.github.com: make.svg · GitHub
01:55:00 <heat> a *lot* of waiting, and i'm pretty sure a good bit of it is just waiting for the vterm ://
01:55:00 <heat> (can't be arsed to make an off-cpu one atm)
01:56:00 <mjg> do the test i dpasted
01:57:00 <mjg> i'm bailin'
01:57:00 <heat> no i'm busy doing more fun stuff
01:57:00 <heat> important to note that my system sucks harder in some will-it-scales cuz i didn't actually batch LRU yet
07:51:00 <geist> yes.
08:33:00 <kazinsal> someone on the internet challenged me to write an amd64 emulator that runs on an 8088 and I'm having a very VERY hard time not rising to the obvious nerd sniping bait
08:34:00 <GeDaMo> https://news.ycombinator.com/item?id=40927438
08:34:00 <bslsk05> ​news.ycombinator.com: Things I learned while writing an x86 emulator (2013) | Hacker News
08:34:00 <GeDaMo> The link is actually from 2023
08:35:00 <mjg> oh no
08:36:00 <mjg> > Most of it totally useless unless you want to write an emulator (which I highly recommend if you ever get the chance).
08:37:00 <mjg> i get you have a kink mate, but don't recommend it to people ffs :P
08:38:00 <kazinsal> the idea of emulating an x64 system at like, 30 instructions per second on a 4.77 MHz 8088 intrigues me in the "purely theoretical dumb idea" sense
08:39:00 <vdamewood> kazinsal: Don't forget working around memory lim its
08:39:00 <vdamewood> limits
08:39:00 <kazinsal> but it's up there with "actually make a serious attempt at my hypothetical osdev project" and "quit my job and reinvent space combat MMORPGs"
08:39:00 <mjg> despite what the osdev wiki used to say there are jobs doing kernel stuff
08:40:00 <kazinsal> my degree's in the wrong field
08:40:00 <mjg> and chances are you can get both the weird shit you want *and* get paid to do it
08:40:00 <kazinsal> but thankfully I'm in a wonderful unionized position with a few people above me who are planning on retiring soon and thus giving me fat promotion tracks
08:41:00 * kazinsal I will never need to argue for raises ever again and can write off many thousands of dollars on my taxes until I retire
08:41:00 <kazinsal> so I can just eventually go back to doing weird kernel shit for fun
08:42:00 <kazinsal> once I get motivated to do so
08:43:00 <GeDaMo> https://www.youtube.com/watch?v=5RF45uEaFlU 8-bit CPU emulating a 386
08:43:00 <bslsk05> ​'Flea86 PC board running Windows 3.0' by dosgamer74 (00:03:33)
08:48:00 <kazinsal> my longstanding april fools osdev joke idea was to reimplement one of the early C versions of research unix for the 5150, as a pastiche of the dozens of early partial reimplementations of unix that were posted to the osdev forums over the years and then immediately abandoned
08:48:00 <kazinsal> but it feels kind of pointless now that nobody seems to have any sort of control or ownership of the forums and wiki
08:49:00 <Mondenkind> '30 instructions per second' nahhh i bet you can do more than that
08:49:00 <Mondenkind> only one way to find out though~
08:49:00 <kazinsal> someone uploaded a new forums theme a while back but apart from that the forums are basically abandoned
08:50:00 <kazinsal> chase used to check in a couple times a year but now no one has sudo perms on the server
08:50:00 <kazinsal> so I expect osdev dot org will disappear when his credit card expires
08:52:00 <Mondenkind> :\
08:55:00 <adder> I'm trying to iterate over multiboot mmap and map those ranges before going long, but I'm getting these pretty pics instead of output: https://imgur.com/uZN7xty.png
08:55:00 <bslsk05> ​imgur.com <no title>
08:55:00 <kazinsal> I logged into the forums to check and apparently a month ago chase just gave everyone with a higher post count than him moderator permissions.
08:55:00 <kazinsal> I believe the kids would call this a big yikes
08:55:00 <adder> I'd guess somehow VGA buffer ends up fucked up but how?
08:57:00 <adder> I even have a check if address is lower than 1MB then not map it
09:03:00 <zid> and where did you write those mappings to?
09:03:00 <zid> Looks like you picked b8000 to have a page table on it, visually :P
09:04:00 <adder> hey zid
09:04:00 <adder> hope ya don't mind, I'm using your bootstrap example as a reference
09:05:00 <adder> I'm pretty much following along, I have code up on github if you wanna look?
09:05:00 <kazinsal> identity mapping identity mapping *banging on table* IDENTITY MAPPING IDENTITY MAPPING
09:05:00 <adder> displaced* identity mapping
09:14:00 <adder> this doesn't look good CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
09:14:00 <adder> right?
09:34:00 <adder> ok, pretty pic gone, pretty sure it was ub
10:17:00 <adder> I need help understanding/fixing a linker error
10:19:00 <adder> kernel/main.c:4:(.text+0x5): relocation truncated to fit: R_X86_64_32 against `.rodata.str1.1'
10:19:00 <clever> adder: try running `objdump -dr main.o`, you there should be a type code on the relocation at offset 5
10:20:00 <adder> this is what I see, clever
10:20:00 <adder> https://termbin.com/f7is
10:21:00 <clever> ah, the code was in the original error, R_X86_64_32
10:21:00 <clever> i think it wants a 32bit absolute address for that string in .rodata
10:21:00 <clever> so the question then becomes, what does your linker script say about .rodata?
10:22:00 <adder> I have two scripts, one for bootloader, one for kernel
10:22:00 <clever> the kernel one matters when linking the kernel
10:22:00 <adder> I'll paste in a moment
10:22:00 <adder> https://bpa.st/COFQ
10:23:00 <bslsk05> ​bpa.st: View paste COFQ
10:23:00 <clever> yeah, that wont fit into a 32bit address without some sign extension
10:24:00 <clever> there is probably a better fix, but try -mcmodel=large?
10:25:00 <adder> would that be a linker flag?
10:25:00 <clever> compiler flag
10:26:00 <clever> 4: bf 00 00 00 00 mov $0x0,%edi
10:26:00 <clever> 5: R_X86_64_32 .rodata.str1.1
10:26:00 <clever> the problem, is that this opcode only accepts a 32bit addr
10:26:00 <clever> so when turning c into asm, it has to make a different choice
10:26:00 <adder> right, this compiles
10:27:00 <adder> thannks clever
10:27:00 <clever> the thing i dont understand, is that kernels typically dont use the large model
10:27:00 <clever> so what is the proper fix?
10:27:00 <clever> pc relative? try -fPIC without large?
10:27:00 <clever> compare what the `objdump -dr` says for each?
10:29:00 <adder> https://termbin.com/j75f
10:30:00 <clever> ah yeah, thats doing pc relative
10:30:00 <clever> so now the requirement is that .rodata is within 2gig of .text
10:30:00 <clever> and 64bit addressing is possible
10:31:00 <clever> adder: https://bpa.st/QEOA you can see it better in here
10:31:00 <bslsk05> ​bpa.st: View paste QEOA
10:32:00 <clever> by default, it wanted a 32bit addr, large made it a 64bit addr (but now your .text is much larger)
10:32:00 <clever> pic made it a 32bit offset
10:33:00 <adder> I'm pretty sure I'm doing something dumb somewhere as I'm still trying to learn the ropes
10:35:00 <adder> does anyone see anything obvious at first sight, why are cr3/etc not changing? https://github.com/NukedOne/rzav/blob/long/boot/boot.S#L48
10:35:00 <bslsk05> ​github.com: rzav/boot/boot.S at long · NukedOne/rzav · GitHub
10:35:00 <clever> i'm less familiar with x86, so i cant help there
10:39:00 <zid> AT&T
10:54:00 <nikolapdp> adder you are using multiboot, no?
10:56:00 <adder> yeah nikolapdp
11:04:00 <adder> why nikolar? please don't suggest limine :D
11:04:00 <nikolapdp> why not
11:04:00 <adder> it's cheating
11:05:00 <nikolapdp> how's that cheating
11:05:00 <adder> idk, somehow feels so
11:11:00 <adder> fuck, I'm getting 0xe
11:21:00 <adder> could be that my printf call from kernel is triggering a page fault?
11:21:00 <clever> adder: how is the stack pointer being configured before kmain gets ran?
11:22:00 <adder> I set it to the stack_top label
11:22:00 <clever> where is it set?
11:23:00 <adder> clever, here https://github.com/NukedOne/rzav/blob/long/boot/boot.S#L79
11:23:00 <bslsk05> ​github.com: rzav/boot/boot.S at long · NukedOne/rzav · GitHub
11:23:00 <adder> stack_top is at the bottom
11:23:00 <clever> and the jmp on line 80, jumps to where?
11:24:00 <adder> to here https://github.com/NukedOne/rzav/blob/long/boot/mem.c#L151
11:24:00 <bslsk05> ​github.com: rzav/boot/mem.c at long · NukedOne/rzav · GitHub
11:24:00 <clever> ah, the entry from the kernel elf headers
11:24:00 <clever> so, is $stack_top a virtual or physical addr? is the MMU mapping that correct?
11:24:00 <adder> I'm not sure tbh
11:25:00 <clever> do `objdump -d bootloader.elf` and read the generated code
11:26:00 <adder> 71: bc 00 40 00 00 mov $0x4000,%esp
11:26:00 <adder> how can I tell if it's virtual or physical?
11:27:00 <clever> did you map 0x4000 in your paging tables?
11:27:00 <adder> no, it's too low
11:27:00 <clever> then its probably physical
11:27:00 <clever> keep in mind, your kernel is trying to use the bootloader stack, thats generally bad
11:27:00 <adder> ah yes fuck
11:27:00 <clever> you need another boot.S for the kernel, that uses the kernel stack
11:28:00 <clever> https://github.com/NukedOne/rzav/blob/long/boot/boot.S#L79 then you can ditch this line
11:28:00 <adder> alright
11:28:00 <clever> https://bpa.st/COFQ and the ENTRY here, needs to point to the helper in the kernel boot.S
11:28:00 <bslsk05> ​bpa.st: View paste COFQ
11:28:00 <clever> which sets the sp, and calls kmain
11:29:00 <adder> ok
11:34:00 <clever> adder: another thing to keep in mind, when switching from physical to virtual, you need an identity map in place
11:34:00 <clever> https://github.com/NukedOne/rzav/blob/long/boot/boot.S#L65-L80
11:34:00 <bslsk05> ​github.com: rzav/boot/boot.S at long · NukedOne/rzav · GitHub
11:35:00 <clever> adder: is the $longmode on line 70 going to be physical or virtual? between lines 60 and 70, the PC will still be physical
11:35:00 <clever> so you need to map that region in identity mode
11:41:00 <adder> clever: the region... around $longmode?
11:43:00 <clever> adder: and also go_long
11:44:00 <adder> but how can I know which region is that?
11:44:00 <adder> do I need to hardcode something?
11:44:00 <clever> you need to take the address of the function (or just the whole bootloader), page-align it, and map it
11:48:00 <adder> thanks clever
11:52:00 <clever> adder: there is also a trick i use for the stack, that doesnt use .skip in asm
11:52:00 <clever> https://github.com/librerpi/rpi-open-firmware/blob/master/firmware/linker.ld#L43-L51
11:53:00 <bslsk05> ​github.com: rpi-open-firmware/firmware/linker.ld at master · librerpi/rpi-open-firmware · GitHub
11:53:00 <ddevault> anyone happen to have the ARMv7 ABI specification handy
11:53:00 <clever> adder: one example, where its using math in the linker script, to just put it at the top of ram
11:53:00 <clever> ah, the other examples i had, do the same thing
13:51:00 <adder> I'm not sure how to align what goes into CR3
13:52:00 <Mutabah> In what way?
13:53:00 <Mutabah> Just allocate a 4KB aligned piece of memory (e.g. at link time, or with your page frame allocator)
14:03:00 <adder> Mutabah, can you show me how? no matter what I do, it ends up something like CR3=00105868
14:03:00 <adder> wait, that's aligned?
14:04:00 <Mutabah> It's worth noting that there are flag bits in there - although, I think most are writable
14:05:00 <Mutabah> How are you setting it? and how is that value generated?
14:07:00 <adder> so I have struct page_table *pml4; as a global variable, and then when I call asm routine to transition into long mode, I pass (uintptr_t)pml4
14:09:00 <Mutabah> and how is `pml4` set?
14:09:00 <adder> minor correction... I realized I was passing a pointer-to-pointer, now when I just pass a pointer directly I'm seeing CR3=00004000
14:09:00 <Mutabah> (also, that's a logical/linear address - not a physical one, that's only correct _before_ paging is enabled)
14:10:00 <adder> pml4 is alloc'd
14:10:00 <Mutabah> I assume you've found your bug?, now that you have an aligned value
14:11:00 <adder> well, almost, still getting a page fault
14:11:00 <Mutabah> is the contents of PML4 valid?
14:12:00 <adder> wait... need to debug
14:12:00 <Mutabah> And you need to ensure that the code you're currently running is still mapped in this new address space
15:40:00 <kof673> > for the 5150 i notice openwatcom says it can generate i86 code, but seems to be missing library functions (unless this is just the way linux binaries were built, or maybe was never "fixed" when it went "open") :/ so possibly it still can, but is perhaps "freestanding"
15:46:00 <kof673> i also notice it needs target specified for both compiling and linking...else like smallerc, it will just output elf even if you specified the compiling target otherwise lol the latter only, unrecognized objects lol
17:19:00 <nikolapdp> KERNAL
17:24:00 <heat> kern
17:25:00 <mjg> uts
17:25:00 <nikolapdp> krnl
17:26:00 <SGautam> So I've a problem, for some reason INT 1Ah, AH=00h seems to misbehave in both BOCHS and QEMU
17:27:00 <SGautam> Sometimes I get the value of ticks in DX, but other times, I simply get 0.
17:27:00 <SGautam> I'm not sure what could cause it.
17:28:00 <Ermine> k
17:28:00 <heat> korn
17:28:00 <SGautam> kornography?
17:28:00 <Ermine> SGautam: I think it's seabios issue
17:28:00 <SGautam> hmm
17:29:00 <SGautam> BOCHS uses SeaBIOS as well?
17:29:00 <heat> probably yeah
17:29:00 <Ermine> idk about bochs, but qemu definitely uses it
17:30:00 <netbsduser> i would've thought bochs would've invented their own
17:30:00 <netbsduser> seabios seems to be very new
17:30:00 <netbsduser> only invented in 2008
17:31:00 <heat> who the heck uses bochs anyway
17:31:00 <netbsduser> it's everywhere in old posts on the osdev forums
17:31:00 <netbsduser> i think it was once regarded as excellent in debuggability
17:31:00 <netbsduser> now QEMU has that really useful GDB remote server built in
17:31:00 <SGautam> Yep, even in 2016 it was the standard go to. QEMU was looked down upon.
17:32:00 <heat> no it wasn't?
17:32:00 <heat> some randos thought bochs was great, but the vast majority of people used qemu
17:32:00 <SGautam> if u used bochs u were part of the cool kids club or something
17:32:00 <SGautam> i guess it was a small community
17:32:00 <heat> the only thing bochs gives you is more info if basic x86 stuff goes wrong
17:33:00 <heat> like, you get a bad segment GPF and it tells you why, exactly, in a log
17:33:00 <SGautam> Yep the console really helps in debugging GDT/IDT faults
17:33:00 <heat> but this is the sort of hello world exceptions that go away quickly
17:33:00 <SGautam> not if you're starting out sir
17:33:00 <heat> >that go away quickly
17:33:00 <SGautam> I recall debugging GDT faults for days at one point
17:34:00 <SGautam> more often than not
17:34:00 <SGautam> a basic course in boolean mathematics and bitwise manipulations is required before osdeving tbh.
17:34:00 <heat> no?
17:34:00 <SGautam> i sort of realised this when x86 docs started making more sense when I understood bitwise math
17:34:00 <heat> bit goes 1, bit goes 0. or, and, xor
17:35:00 <heat> no need for any course in mathematics lol
17:35:00 <SGautam> boolean mathematics is that lol
17:36:00 <SGautam> heat: I used to be that guy reading MUL docs when I wanted to multiply a number by 2 in asm
17:37:00 <heat> thats ok i don't know how to multiply numbers in x86 asm either
17:37:00 <heat> you have mul and imul i think? one of those is good, the other is bad
17:37:00 <heat> might be imul
17:37:00 <SGautam> nah bruh
17:37:00 <SGautam> shl ax, 2
17:37:00 <SGautam> *shl ax, 1 -- actually
17:37:00 <SGautam> that blew my mind when I first realised it
17:37:00 <heat> wonderful obfuscation
17:37:00 <heat> so wonderful you fucked it up
17:37:00 <GeDaMo> Uh, you can use add to multiply by 2 :|
17:38:00 <SGautam> ah yea
17:38:00 <heat> shl will be faster
17:38:00 <Ermine> maybe bochs is MINIMAL?
17:38:00 <SGautam> no way
17:38:00 <heat> bochs is definitely MINIMAL
17:38:00 <Ermine> hah
17:38:00 <SGautam> its a bit of pain to set up
17:38:00 <SGautam> you need a bochsrc
17:38:00 <heat> so MINIMAL it's garbage, as the s6 fans would like it
17:38:00 <SGautam> than just firing up qemu with args
17:38:00 <heat> ideally bochs would have PIPES
17:39:00 <Ermine> R you trying to trigger me?
17:39:00 <heat> yes
17:39:00 <Ermine> mofo
17:39:00 <heat> mofer*
17:39:00 <Ermine> ok mofer
17:39:00 <heat> think about it, an x86 emulator but every instruction spawns a separate process and pipes the result back
17:40:00 <heat> i love it
17:40:00 <heat> but now the separate process is a POSIX sh script running on busybox ash
17:40:00 <Ermine> s6 fans use execline you know
18:08:00 <heat> gog
18:10:00 <gog> heat
18:11:00 <kof673> bochs i thought was c++...qemu ...i don't recall
18:11:00 <kof673> this is not a criticism, just what is needed to build...
18:24:00 <heat> gog, do you have that dawg in you
18:26:00 <gog> can i pet that dawg
18:26:00 <gog> can i pet that daaaaaaawwwg
18:52:00 <mjg> you ok fellaz
18:53:00 <heat> do you have that dawg in you
18:55:00 <nikolapdp> > an x86 emulator but every instruction spawns a separate process
18:56:00 <nikolapdp> there was a guy who wrote a cloud native gameboy emulator
18:56:00 <heat> OH new idea: x86emufs
18:57:00 <nikolapdp> https://blog.davetcode.co.uk/post/21st-century-emulator/
18:57:00 <bslsk05> ​blog.davetcode.co.uk: Bringing emulation into the 21st century - David Tyler's Blog
18:57:00 <heat> every instruction is a file
18:57:00 <heat> registers are files
18:57:00 <nikolapdp> wasn't a gameboy actually
19:14:00 <kof673> well minus the cloud part it was inevitable, it is just unix shell/pipeline model, each process does "one thing." conversely, bash/etc. added more built-ins, i.e. part of the same process.
19:15:00 <kof673> juts different levels of granularity lol
19:32:00 <Jari--> Hi, which OSDEV book to buy if wanting to do application module for the kernel, and trim the memory management?
19:32:00 <Jari--> I had an application module before, but I am rewriting it
19:33:00 <Jari--> Operating System Design and Implementation (3rd Edition) by Andrew S. Tanenbaum? good?
19:48:00 <Ermine> Jari--: so you need to implement a linux kernel module? You can look at LDD3 book, though it's outdated. And you'll need to study kernel documentation
19:52:00 <Ermine> Tanenbaum's book is about development of operating systems with minix 3 as an example. It won't teach you writing kernel modules
19:53:00 <Jari--> Ermine I missed DJGPP, so I wrote lots of DOS compatibility, too, BTW
19:54:00 <heat> it's about minix 3?? i'm afraid it won't teach you anything :(
19:54:00 <Ermine> it will
19:54:00 <Ermine> it contains some generic stuff
19:55:00 <heat> the author of minix writing a book about operating systems is like theo deraadt writing a book about social norms
19:55:00 <heat> change my mind
19:55:00 <Ermine> you can discuss paging in os-independent way for example
19:56:00 <Ermine> that there are pages, there's how processor translates virtual addresses into physical, there is a TLB
19:56:00 <Ermine> that sort of things
20:00:00 <heat> does it ramble about pessimality and crapper code for 300 pages
20:00:00 <heat> if not, pessimal bok
20:00:00 <heat> book
20:02:00 <mjg> the only sensible book describes a shit idea
20:02:00 <mjg> then a less shit idea and claims genius
20:02:00 <Ermine> and theo can write that it is social norm to be cisgender, but many, including me, will disagree
20:02:00 <mjg> anything short of that is not worh reading
20:03:00 <netbsduser> Ermine: de Raadt doesn't write anything about cisgenderism
20:04:00 <Ermine> netbsduser: it's nice, isn't it?
20:06:00 <netbsduser> Ermine: yes, i don't think there is any evidence to suggest de Raadt is bigoted about anything other than anything that isn't under the BSD licence
20:07:00 <heat> theo is bigoted about other people in general
20:08:00 <Ermine> netbsduser: I've got a feeling that he can spew bigotry while reading some mails from openbsd ml. But, indeed, these's no hard evidence
20:09:00 <heat> 'ate the freebsd, 'ate the netbsd, 'ate the linox, luv me openbsd, simple 'as
20:14:00 <heat> Ermine, also worth noting that you'd probably get the same vibe from linus but he's clearly not a bigot
20:18:00 <Ermine> heat: yeah, as far as pre-2018 linus is concerned
20:22:00 <gimli> that guys doug16k is not here anymore right?
20:22:00 <gimli> s/guys/guy
20:22:00 <GeDaMo> Haven't seen him for a while
20:24:00 <kof673> he was sort of in other channels ....within the past year or two maybe...
20:29:00 <chiselfuse> i am trying to understand segments and ldt but i can't find a way to experiment with them on linux. i thought i could step through a process in gdb and print the ldt. i also looked in ida and didn't find anything. do i patch the program memory with a sequence of instructions that syscall modify_ldt(2) in order to check it? is there a simpler way to examine this structure for a running process?
20:30:00 <Ermine> better write some assembly which tweaks ldt and run it in qemu
20:31:00 <netbsduser> i'm still stunned openbsd has an rcu-ish thing now
20:31:00 <Ermine> And nowadays it's not really a useful knowledge, since everyone uses paging
20:32:00 <netbsduser> quite
20:34:00 <zid> you can mess with the ldt with syscalls in linux userspace
20:34:00 <chiselfuse> i can't figure how FS and ldt is used in threads in linux. does each thread have a different ldt? i checked FS and it seems like it's the same for each thread so i assume each must have a different ldt
20:34:00 <zid> idk why you'd want to, but you can!
20:35:00 <Ermine> ldt is unused
20:35:00 <chiselfuse> zid: yea i found modify_ldt(2)
20:35:00 <zid> Linux allows processes to configure
20:35:00 <zid> a per-process (actually per-mm) LDT.
20:35:00 <zid> it's not per thread
20:35:00 <chiselfuse> zid: what's 'mm'?
20:35:00 <zid> no idea, but it isn't a thread
20:35:00 <blockhead> mickey mouse
20:37:00 <chiselfuse> Ermine: but i read that FS must point to a different point for each thread so that they can use it to access local variables at different offsets
20:37:00 <chiselfuse> the FS descriptor i mean
20:37:00 <Ermine> where did you read that
20:38:00 <chiselfuse> Ermine: https://docs.kernel.org/arch/x86/x86_64/fsgs.html
20:38:00 <bslsk05> ​docs.kernel.org: 29.8. Using FS and GS segments in user space applications — The Linux Kernel documentation
20:38:00 <chiselfuse> Ermine: 29.8.1 specifically
20:38:00 <zid> are fsbase and gsbase in x86
20:38:00 <zid> I never did much x86, only amd64
20:39:00 <zid> anyway, WRFSBASE
20:39:00 <chiselfuse> zid: yea they're the only ones allowed to have non-zero base address in their descriptors. all other segment registers are forced to zero AFAIU
20:40:00 <zid> is how you do it, fs just needs to contain a valid *descriptor*, it doesn't actually hold the real base address that [fs:...] uses
20:40:00 <zid> WRFSBASE sets that
20:40:00 <zid> arch_prctl(ARCH_SET_FS, fsbase);
20:41:00 <zid> https://www.kernel.org/doc/Documentation/x86/x86_64/fsgs.rst
20:42:00 <chiselfuse> zid: okay but this doesn't answer my question. i want to know whether each thread has a different value of FS (apparently not after i checked in debugger), and that since they're the same value, whether that implies that each thread has a different LDT so that they may provide a different base for each thread so that they don't write over each others' local variables
20:43:00 <zid> no, they all use the same fs value
20:43:00 <zid> the base is *independent* to the selector, as I mentioned
20:44:00 <Ermine> chiselfuse: you can use arch_prctl call as described in that page
20:44:00 <zid> the base just has to not be invalid wrt to the selector, I think. And most people just.. set the selectors up for 0-4GB range anyway
20:46:00 <chiselfuse> zid: so you say that they have the same FS but that the base address is different in the selector for each thread, ie that each thread has a different segment selector pointed to by the same FS, and since that selector is part of the LDT, that each thread has its own LDT
20:46:00 <chiselfuse> oh wait you said the base is independent to the *selector*
20:46:00 <zid> same segement selector
20:46:00 <zid> different *completely seperate*, weirdly set with a special opcode, base
20:47:00 <chiselfuse> i thought the segment selector contained the base address
20:47:00 <zid> it does, for what addresses are valid
20:47:00 <zid> but not the actual base address used by the *addressing*
20:47:00 <gimli> kof673: which channles?
20:47:00 <zid> do you know the 16bit segmentation scheme? it's kind of a weird mix of that, and pmode segmentation
20:48:00 <zid> fs and gs act like 16bit segmentation, where they contain a base address which is added to the pointers that use that selector, but it also has a pmode style selector which does range checking
20:49:00 <gcoakes> Could someone help me to understand the available options for pivoting execution from physical memory to virtual memory for a kernel? I've been reading up on some of the different methods used, and I'm either misunderstanding it or dissatisfied with the status quo. As I understand it, you can either:
20:49:00 <gcoakes> - Write your pre-MMU code in architecture specific assembly and your kernel is linked as if it runs from virtual memory. (Linux, I think)
20:49:00 <gcoakes> - Compile two different artifacts which are linked for (1) physical memory and (2) virtual memory. Then, you embed #2 within #1. (seL4 elfloader)
20:50:00 <zid> not sure what assembly has to do with it
20:50:00 <zid> but either way you need a page you know the address of, which contains the 'switch the mmu on' code, which is identity mapped, and another, virtual map of everything
20:51:00 <gcoakes> Well, I guess you write the pre-MMU code in such a way that no pointers leak past the MMU enable barrier.
20:51:00 <zid> You need that identity mapped page, else the instruction that switches virtual memory on will stop having a valid instruction pointer underneath it at the moment you switch
20:51:00 <zid> you can unmap it after
20:52:00 <zid> (and you will want to, lest you have a small hole in the low addresses)
20:52:00 <chiselfuse> zid: [this](https://wiki.osdev.org/Segment_Selector) structure is one of the entries in the LDT, right? if FS is 3, then it refers to LDTR+(16*3). the base address [3-15] in this entry is the base address. so if i see an instruction `mov rax [fs:0xA]` that gets executed by multiple threads, they'll be adding 0xA to the same base address (specified in that entry). so how is it that they end up with
20:52:00 <bslsk05> ​wiki.osdev.org: Just a moment...
20:52:00 <chiselfuse> separate local variables?
20:52:00 <zid> am I reddit now
20:53:00 <zid> chiselfuse: again, that is for the *range checking*
20:53:00 <zid> the address calculation is fsbase+offset
20:53:00 <zid> checked against selector.base - selector.base+selector.limit
20:53:00 <chiselfuse> and what's fsbase? a completely different register than FS or what?
20:53:00 <zid> yes!
20:54:00 <zid> 21:46] <zid> different *completely seperate*, weirdly set with a special opcode, base
20:54:00 <chiselfuse> zid: are you sure? both in the AMD manual and resources like this one https://wiki.osdev.org/Segment_Selector refer to FS, not fsbase
20:55:00 <zid> why would they not refer to fs
20:55:00 <zid> they're about selectors
20:59:00 <zid> intel manual calls it IA32_FS_BASE MSR btw
20:59:00 <zid> If you can't find that, try C0000100H
21:04:00 <chiselfuse> zid: is this it https://0x0.st/XMwe.png
21:04:00 <zid> I guess?
21:07:00 <chiselfuse> hmm i'm reading that they're originially supposed to be caches for the base,limit in the ldt
21:20:00 <kof673> gimli, i think there is a #dos, i say "sort of" because other side of bridge, may be named differently here :D doesn't irc have whois or something? maybe people can be "invisible" to hide though (and hide channels)
21:20:00 <kof673> IIRC he has github, should not be impossible to find
21:21:00 <kof673> some "old" channel anyways, whatever it was :D
21:25:00 <heat> chiselfuse, an 'mm' = address space
21:26:00 <heat> gcoakes, linux's pre-mmu code is not written in assembly but generally careful C
21:26:00 <heat> it's a risky business to write position-independent C, but it usually works fine if you know what you're doing
21:29:00 <kof673> maybe an asm or hw channel, i don't keep logs :D
21:30:00 <netbsduser> i love that linux terminology
21:30:00 <heat> it comes from mm_struct fwiw
21:30:00 <netbsduser> address spaces are mms and vm objects are address spaces
21:32:00 <heat> to be fair, vm objects are also a garbage name
21:32:00 <netbsduser> what's wrong with them?
21:33:00 <heat> it's a horrendously vague undescriptive name
21:33:00 <netbsduser> it seems to be descriptive to me
21:33:00 <heat> what's a "vm object"? object in the vm system? what does this object do?
21:33:00 <netbsduser> in any case it's traditional and accepted
21:34:00 <heat> it really is a terrible name. alas mach came up with it and now we're stuck with that in a bunch of systems
21:35:00 <netbsduser> in mach it has a subtly different purpose and the combination of memory objects and vm objects match more closely how vm objects are understood today, but it's close enough
21:35:00 <netbsduser> i would accept segment as well
21:36:00 <netbsduser> though i might prefer segment to denote the map entry rather than the object mapped
21:36:00 <gcoakes> @heat, I think I was incorrectly generalizing RISC-V to all of Linux's bootstrap. I was reading through `arch/riscv/kernel/head.S` which seems to be where the initial switch happens.
21:37:00 <heat> vm_mappable? or maybe just struct pagecache :^)
21:37:00 <gcoakes> I really just grep'ed for satp register. I don't even really know how head.S fits into the overall build.
21:38:00 <netbsduser> gcoakes: to your question about transitioning from physical to virtual addressing, i see it as a bootloader duty
21:39:00 <netbsduser> on amd64 limine does it for me and on m68k (qemu virt and amiga) i do it myself in a minimal loader
21:40:00 <heat> gcoakes, https://elixir.bootlin.com/linux/latest/source/arch/riscv/mm/init.c#L1045
21:40:00 <bslsk05> ​elixir.bootlin.com: init.c - arch/riscv/mm/init.c - Linux source code (v6.9.8) - Bootlin
21:40:00 <netbsduser> since i only deal with it on the m68k i just enable a transparent translation region for the lower half of the address space and in the kernel i make away with that
21:40:00 <gcoakes> I've used it for years but never quite understood the purpose of the bootloader to this level. So, when GRUB or similar hands over control to Linux, is the MMU typically enabled?
21:40:00 <heat> this is where linux does early page table init for riscv
21:40:00 <heat> gcoakes, no, that's not how bootloaders usually work
21:40:00 <heat> at least on the UNIX/linux side
21:40:00 <netbsduser> grub doesn't do it, multiboot is a more basic protocol
22:16:00 <Jari--> ppl apparently have problems with grub, it has bugs
22:16:00 <Jari--> https://www.youtube.com/watch?v=gBykJMqDqH0&list=PL980gcR1LE3LBuWuSv2CL28HsfnpC4Qf7
22:16:00 <bslsk05> ​www.youtube.com <no title>
22:17:00 <heat_> grub has never had bugs no sir never nuh uh
22:18:00 <chiselfuse> what does segment_selector.rpl=3 do?
22:18:00 <heat_> changes your ring level
22:18:00 <chiselfuse> isn't it only valid from 0-2? what's 3?
22:19:00 <heat_> ring 3...?
22:19:00 <mjg> let me tell what's not going to have bugs: the in-kernel grub replacfement
22:19:00 <Jari--> chiselfuse RPL is the field you're specifically asking about. It is a 2-bit field representing the privilege level of the code that is using the segment selector. The possible values are: 0: Ring 0 (highest privilege), 1: Ring 1, 2: Ring 2, 3: Ring 3 (lowest privilege)
22:19:00 <chiselfuse> oh nvm i thought there were only 3 rings not 4
22:19:00 <zid> What *is* 3?
22:19:00 <zid> you thought ring3 was ring numerical 2?
22:20:00 <zid> good thing about binary is that you get a fourth for FREE
22:20:00 <zid> because otherwise you're just wasting the 0b11 encoding
22:20:00 <chiselfuse> zid> you thought ring3 was ring numerical 2?
22:20:00 <chiselfuse> yea lol
22:21:00 <Jari--> just run the shit in root level
22:21:00 <Jari--> add features later :)
22:21:00 <heat_> linus torvalds vs andrew tannenbaum, colorized
22:22:00 <zid> Everybody asks what is three, but nobody ever asks HOW is three? :(
22:22:00 <chiselfuse> king terry
22:23:00 * kof673 inserts terrance howard joke
22:23:00 <Jari--> and the order matters? I think not. You can have Ring0 as an application mode processes, if you want? not?
22:25:00 <Jari--> chiselfuse so basically it is just an order number, it can be set as anything you want it to be
22:28:00 <chiselfuse> huh?
22:53:00 <adder> I need help figuring out why I'm getting a page fault. when I grep for exceptions, I see (old, new) = {(0xffffffff, 0xe), (0xe, 0xd), (0x8, 0xd)} (which kind of doesn't make sense to me). these are my control registers `CR0=80010011 CR2=0000000000000024 CR3=0000000000111000 CR4=000000a0` I tried disassembling address in CR2 to see what is causing the fault but no luck, out of bounds / no function contains that address
22:53:00 <adder> thoughts?
22:53:00 <heat_> you're trying to access 0x24 but it's unmapped
22:54:00 <adder> just one sec... I am compiling the whole thing in a really weird way
22:54:00 <heat_> and then what looks like subsequently faulting for related/unrelated corruption
22:54:00 <adder> how am I supposed to compile this?
22:54:00 <heat_> this = what?
22:54:00 <adder> like I have a sprinkle of .code64
22:54:00 <adder> and then I have a x86_64 kernel
22:55:00 <adder> and using my 32-bit cross compiler gets me in all kinds of issues
22:55:00 <adder> so I'm using -fPIC
22:55:00 <adder> (no idea what that is)
22:55:00 <heat_> obviously if its a x86_64 kernel you can't use your 32-bit cross compiler
22:55:00 <adder> do I need two compilers?
22:55:00 <heat_> you need a single x86_64-elf compiler
22:55:00 <adder> yeah but one for the bootloader?
22:56:00 <heat_> why do you have a bootloader?
22:56:00 <heat_> and in any case x86_64-elf with -m32 should probably work
22:56:00 <adder> wdym why do I have a bootloader? genuine question
22:57:00 <heat_> are you not using grub?
22:57:00 <adder> yeah I am
22:57:00 <heat_> or limite or whatever
22:57:00 <heat_> well, then that's the bootloader
22:57:00 <adder> by bootloader I meant the part the inits idt,gdt,remaps pic, transitions into long, and transfers control to kernel
22:57:00 <heat_> that's not how things are usually done
22:58:00 <heat_> usually it's all a single kernel, a very very minimal bit in 32-bit that bootstraps you up to long mode. idt, gdt, pic, whatever are all post-long-mode
22:58:00 <adder> oh
22:59:00 <adder> heat I think I'll start over
22:59:00 <adder> this is a fuckin mess
23:04:00 <Reinhilde> that's valid
23:18:00 <adder> .text 0xfffffffff80002f0 0x18 kernel/main.o
23:18:00 <adder> 0xfffffffff80002f0 kmain
23:20:00 <gcoakes> @adder, you mentioned not knowing what -fPIC is. It should be position independent code.
23:58:00 <adder> so do we want pic in osdev or not?
23:58:00 <adder> I think it's pagefaulting when I try to panic
23:58:00 <adder> how on earth is this not mapped
23:58:00 <adder> .eh_frame 0x0000000000105360 0x24 boot/panic.o