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=osdev&y=19&m=5&d=9
06:01:32 <geist> yawn. good morning folks
06:02:25 <eryjus> good morning
06:03:22 <geist> unusually quiet the last day
06:04:09 <eryjus> i noticed that too...
06:06:37 <zid> Everybody is hiding from me
06:09:41 <geist> sssh, maybe they'll notice we're not here...
06:38:22 <ZetItUp> you ruined a perfect idling channel :(
06:39:32 <aalm> .theo
06:39:32 <glenda> I don't see any humility.
07:10:20 <AndyHD> would it possible to build an OS based on kotlin?
07:24:03 <geist> good question
07:24:30 <mischief> it's called android
07:24:36 <geist> the main question is a matter of definition. ie, what layers of the system are in kotlin
07:24:50 <geist> it's probably not easy to write a low level kernel in one, but the higher layers, sure
07:25:33 <geist> and yeah, android is an example of something where a lot of the higher layers are written in java like languages
07:56:27 <Kazinsal> seconded, it's perfectly feasible to build a *system* in any language, so long as you've written a kernel and whatever support libraries you may need for it in a language you can do that in with reasonable efficacy
07:57:58 <geist> right, also doggedly writing something in a language end to end is not always the best engineering idea
07:58:28 <geist> use the right language for the job. that's still debatable and clearly everyone has opinions, but there are certain languages that just really aren't that suitable for low level code
07:58:49 <geist> which is fine, because mixing languages, especialyl in something as complex as an entire operating system, is very common and well established
07:59:41 <Kazinsal> yeah I would not recommend deciding you really like lua and therefore you're going to write as much of the system as possible in it
08:01:53 <mischief> what do you have against lua
08:03:59 <geist> entirely the wrong thing to read from that statement
08:04:12 <Kazinsal> nothing, just that it's a terrible language to write a kernel in
08:04:41 <Kazinsal> or a firewall, or a word processor, or a BGP router
08:07:06 <graphitemaster> geist, did you get that video I linked you the other day?
08:07:13 <geist> not sure, what was it?
08:07:44 * mischief goes and writes a firewall, word processor and bgp router in lua
08:08:19 <geist> mischief: nothing keeps you from it, the point is clearly being lost here
08:09:15 <graphitemaster> geist, awesome video on the 4012 tektronix
08:09:26 <geist> ah. no didn't see that
08:09:26 <graphitemaster> https://cdn.discordapp.com/attachments/256212041390489601/538105781204025344/cursed.webm
08:09:38 <graphitemaster> I wish I could find the full version of this
08:09:43 <graphitemaster> someone linked it on Discord
08:09:45 <geist> oh that's right, i remember getting that link but for some reason my browser sees that as a file and tries to download
08:09:53 <graphitemaster> just launch it in mpv
08:10:06 <geist> oh webm is some sort of video file, got it
08:10:07 <graphitemaster> it's because Discord does not send the appropriate meta data and mime info
08:10:15 <geist> yah i was on a chromebook at the time
08:10:32 <graphitemaster> this was an ad for it back in the day btw
08:10:35 <graphitemaster> the music and all
08:11:17 <geist> nice
08:12:03 <geist> at the vintage computer festival a month ago or so someone had an old tek scope hooked up to a pdp8 driving spacewar
08:13:01 <graphitemaster> ah found the whole thing https://www.youtube.com/watch?v=YZsiR45tKKw
08:13:44 <graphitemaster> maybe it was not an original ad
08:13:51 <graphitemaster> going by the song and all that
08:13:59 <graphitemaster> I got bamboozled on Discord, dammit
08:14:03 <graphitemaster> still a cool video
08:14:07 <geist> yah that's a somewhat more modern song i think
08:14:24 <graphitemaster> it's from tron legacy https://www.youtube.com/watch?v=t9qaEVLHo6Y
08:14:36 <geist> yah thought it was daft punk
08:14:53 <graphitemaster> I like it
08:15:11 <geist> that whole album is quite too (tron legacy soundtrack)
08:15:15 <geist> good even
08:16:55 <graphitemaster> I've never seen tron legacy
08:16:59 <graphitemaster> any good?
08:17:06 <geist> eh.
08:18:44 <graphitemaster> well, I think I'd like the music
08:22:27 <graphitemaster> I forgot how memorable Daft Punk music is
08:22:42 <graphitemaster> They've had a lot of really good tracks
08:24:18 <geist> yah as much as i'm not really into that kind of music, they're really good
08:28:32 <graphitemaster> They have some catchy tracks
08:41:06 <AndyHD> geist: kotlin is also working an native compile...
09:06:53 <geist> neat
09:26:27 <glauxosdever> What about this one? https://www.youtube.com/watch?v=wzRQ1RxF_fc
10:18:13 <androidirc> Hi, i have a question. I just finished setting up the 64-bit part of my os(im the guy who asked about pushing & poping cs a few days before, and thank to you guys, it works fine in 64-bit long mode!).but, when i try to enable acpi, specifically when reading the rsdp, it gives a #GP, which i think comes from a page fault. Bochs says: access_read_linear(): canonical failure, which AFAIK means that there's something wrong with paging. Also lets say the thr
10:18:51 <zid> sounds like the address you used wasn't canonical to me
10:19:08 <eryjus> canonical failure means that the address is not in canonical form -- bit extended to 64 bits
10:19:23 <zid> aka not between -128TB and +128TB
10:19:46 <androidirc> Yes, but the mapping seems finee, from 0-4mb
10:19:51 <eryjus> so, whatever bit you have in 47, needs to be repeated in 48:63
10:19:58 <zid> triple check the value of the reg you dereferenced
10:21:20 <androidirc> zid, what do you mean with the reg i dereferenced?im sorry if its too obvious
10:21:26 <zid> register
10:21:31 <zid> you accessed memory through one
10:21:36 <zid> check its value
10:21:37 <zid> three times
10:21:41 <zid> to make sure it is sane
10:22:04 <androidirc> Ok. I'll try
10:22:43 <eryjus> androidirc, just double checking -- do you know what a canonical address is?
10:23:45 <androidirc> i readed it, but i cant remember at all the exact definition
10:23:57 <zid> > between -128TB and +128TB
10:25:03 <androidirc> Ok, so that means that its trying to read over(or under) 128tb? Thats not sane. Ill check
10:25:54 <eryjus> well, a 64-bit cpu only uses 48 bits for addresses. therefore, something needs to be done with bits 48:63 with any address. These *must* have bit 47 extended through bit 63. If these are not the same, then the address is not canonical (or normalized)
10:26:56 <eryjus> so, as zid mentions, you will need to look at your address that is creating the issue and validate that it meets those rules. The address causing the #GP will not.
10:28:07 <androidirc> Ok. i cant see a non canonical adress, all mappings are just fine. Im accesing(for searching rsdp) directly from 0xE0000 to 0x100000.
10:28:15 <zid> It's nt about mappings
10:28:21 <zid> It's about virtual addresses
10:28:26 <zid> the actual value of the pointer
10:29:00 <androidirc> ok. Now i understand :-)
10:29:51 <eryjus> my bet is you are looking at a 32-bit address as a 64-bit address and picking up some additional bits you did not intend....
10:35:51 <androidirc> Ok. Qemu says, from 0 to 0x3fe00000 all with bit p and w set
10:35:59 <zid> Don't look at mappings.
10:36:05 <zid> Look at the faulting instruction.
10:36:26 <zid> This has nothing to do with mappings, you're using an invalid address. Which means you have some garbage in a register somewhere.
10:40:43 <androidirc> Ok. Rax: 0xe0000000, rbx: 0x108, rcx: c00000080, rdx: 0, rsp: 0x121fe0, rbp: 0x121ff0, rip: 10013f
10:40:57 <zid> and what is the instruction?
10:41:35 <androidirc> Mov eax, 0
10:41:41 <zid> No, it isn't, lol
10:43:31 <androidirc> im sorry. Did i mistake in somethin?. I stopped just before calling the search rsdp instruction.then i did info cpu on bochs(im pretty sure i did something wrong, im pretty dumb when understanding something)
10:45:29 <geist> it's possible. but it could be that the rdsp is up in the top part of the 4GB space
10:45:45 <geist> but, yeah i bet rdsp is down below
10:46:01 <geist> what can happen is if you start running bytecode, it may try to then access some pci control registers and whatnot
10:47:24 <androidirc> Ok. But im sure its below the 4gb. I used the same code when i didnt have 64-bits and it worked fine.
10:48:57 <geist> then that instruction doesn't seem right
10:49:30 <geist> or it's is the instruction, and thus it explains the failure (derefercing address 0xe000.0000)
10:49:39 <geist> which doesn't make sese given what you've told it to do
10:51:54 <androidirc> well, it sure doesnt.
10:55:37 <geist> next thing i'd do is figure out which address it faults on
10:56:03 <androidirc> Ok. Now it makes more sense. Seeing whats in the address between 0xE0000, and 0x100000 says its bogus. in 0x100000, it even has the value of the multiboot magic value(0x1BADB002).
10:56:13 <androidirc> Ok geist, ill see
11:04:09 <androidirc> Ok. Faulting address: 0x000F68C1, cointains 0x0040b8e2.
11:10:32 <doug_16k> mov eax,0 can page fault if the instruction fetch faulted
11:11:11 <doug_16k> could be execute-disabled, so it looks ok, but isn't
11:11:40 <doug_16k> could look ok if it is supervisor permission and user code fetches execute-allowed page
11:12:05 <doug_16k> debugger shows you the mov just fine, can't be fetched by cpl 3
11:12:17 <doug_16k> possible I mean, not saying that is it
11:13:57 <androidirc> Yes, but the instruction mov eax, 0 is not the one faulting, its my error. The instruction faulting is mov rax, qword ptr ss:[rbp-8].
11:14:12 <doug_16k> ah. just got here, not following 100%, sorry
11:14:26 <androidirc> dont worry :-)
11:14:41 <_mjg> please don't mov eax, 0
11:15:08 <_mjg> xor!
11:15:18 <_mjg> (and i'm not picking on it, this is recognized as a zeroing idiom)
11:15:23 <_mjg> (by the cpu)
11:15:27 <androidirc> And i dont;i dont even know why bochs is saying that
11:15:51 <eryjus> androidirc, so what in rbp?
11:15:58 <doug_16k> yeah, xor a register with itself is special cased to an op that loads zero into a register extremely efficiently
11:16:49 <androidirc> In rbp is 0x00121f70
11:17:41 <doug_16k> androidirc, what does this say: x /1gx $rbp-8
11:18:49 <doug_16k> does it say "unable to access memory"?
11:19:00 <doug_16k> or something to that effect
11:19:33 <androidirc> Says syntax error. Nothing about unable to access memory
11:19:41 <doug_16k> oh, bochs?
11:19:53 <androidirc> Yes
11:19:59 <zid> bochs has 'page' conveniently, when are you adding that to qemu doug? :)
11:20:25 <doug_16k> zid, someday. thought has crossed my mine a lot
11:20:43 * eryjus waits with great anticipation
11:20:53 <doug_16k> androidirc, you need my bochs fork, which adds 64 bit support to 'x' :) what does this say: x /2wx $rbp-8
11:24:23 <androidirc> Syntax error at $rbp
11:24:50 <doug_16k> ah, remove $ I guess. I'm getting rusty at bochs debugger
11:25:47 <androidirc> Ok. Says: 121f68 <bogus+ 0>: 0x000E0000 0x0
11:26:19 <doug_16k> what does this say: page 0x121f68
11:28:03 <doug_16k> ah you have official bochs don't you. I fixed info tab and page for x86_64 too
11:28:22 <doug_16k> bochs adopted a big chunk of my changes but not all
11:28:24 <zid> ss buggered?
11:28:54 <doug_16k> ss is ignored in ring 0 long mode
11:28:55 <zid> doubt that'd be the first place you'd see it though
11:29:13 <doug_16k> well, partially ignored
11:29:22 <doug_16k> ss RPL must be == cs RPL
11:29:45 <doug_16k> it would die earlier if it was that
11:30:23 <androidirc> PML4: 0x0000000000110023 ps A pcd pwt S W P PDPE: 0x0000000000111023 ps A pcd pwt S W P PDE: 0x000000000000e3 PS g pat D A pcd pwt S W P linear page: 0x0000000000121000 maps to phys (well the same as linear one)
11:30:39 <doug_16k> oh good it does have my fix
11:30:53 <androidirc> it seems so :-)
11:32:50 <doug_16k> PDE is at address zero?
11:33:05 <doug_16k> er, page table is I mean
11:33:06 <androidirc> no. E3
11:33:21 <doug_16k> page tables must be 4KB aligned
11:33:29 <doug_16k> E3 makes no sense
11:33:49 <doug_16k> those are the flag bits
11:34:12 <doug_16k> the low 3 digits of hex are not part of the address. this seems to indicate that the page table begins at address 0
11:34:48 <androidirc> ok. Anyways i was saying pde e3
11:36:24 <doug_16k> I meant E3 as a PDE entry doesn't make very much sense because that means that the page table begins at physaddr 0 doesn't it?
11:36:36 <androidirc> well, yes
11:37:00 <doug_16k> that could work... but it is weird
11:37:49 <androidirc> Yes. But its normal that bochs says that memory is bogus?(AFAIK that means its wrong)
11:38:03 <doug_16k> that will say bogus if you don't load symbols
11:38:44 <androidirc> Ok.
11:38:46 <doug_16k> it is reverse looking up the symbol there. no symbols = bogus
11:40:23 <doug_16k> you can generate symbols for bochs and load them and the debugger will be symbolic
11:40:40 <androidirc> ok.
11:41:04 <androidirc> But i still dont understand why its failing
11:41:31 <doug_16k> ah!
11:41:39 <doug_16k> I see why PDE looks funny, it's a huge page
11:41:51 <doug_16k> 000...E3 is fine then
11:42:48 <doug_16k> androidirc, can you run r command and say what is in cs, ds, and ss?
11:43:01 <doug_16k> or is it info seg or something?
11:43:32 <gog> info tlb
11:43:46 <gog> oh bochs not qemu sorry
11:43:51 <doug_16k> it would be info tab in bochs
11:44:16 <gog> how can i make my symtab sections SHF_ALLOC?
11:44:39 <alberinfo_osdev> my irc app crahed.f**k me
11:45:19 <doug_16k> gog, forceful way is objcopy
11:46:01 <gog> maybe
11:46:03 <doug_16k> you could also assign them to a program header section that is loaded
11:46:18 <doug_16k> you want them loaded right?
11:46:20 <gog> yeah
11:46:37 <gog> they're included in PT_LOAD sections but the linker doesn't adavnce the counter
11:46:44 <gog> obv because the section isn't SHF_ALLOC
11:47:05 <gog> so my output tells me the section is empty and might as well not exist
11:47:09 <doug_16k> does it have an address?
11:47:13 <gog> nope
11:47:17 <gog> vaddr and paddr are 0
11:47:21 <gog> filesz is 0
11:47:31 <doug_16k> then there is no symtab?
11:47:51 <gog> there's a symtab and its offset according to the section header table is right
11:48:08 <gog> but in the phdrs, like i said, ld doesn't advance the location or segment size counters
11:48:12 <doug_16k> I'd assign an address to it
11:48:36 <doug_16k> .whatever ALIGN(4K) : { ... <-- should do it
11:48:37 <gog> the output section has an address
11:48:49 <doug_16k> ah
11:48:51 <gog> yeah it's set to CORE_DATASEG
11:48:54 <gog> whatever that is rn
11:48:58 <gog> somewhere in -2GB
11:49:40 <gog> i'll keep digging in the ld manual even though i've read it three times i think lol
11:50:38 <doug_16k> mine load
11:51:16 <doug_16k> https://gist.github.com/doug65536/21f41c1af1bb658300dec96c182b84c9
11:51:36 <doug_16k> gog, ^
11:52:13 <doug_16k> I load dynamic kernel modules, they link against kernel using that symtab, so it definitely works
11:52:44 <gog> you have dynsym and dynstr but i don't see symtab or strtab
11:53:02 <doug_16k> same thing
11:53:31 <doug_16k> I named it that because I find it using the .dynamic section contents I guess
11:54:35 <gog> no i think dynsym and dynstr have different handling than static symstab and strtab
11:54:48 <gog> but again i need to go through the ld manual again see if i missed smth
11:54:52 <doug_16k> symbols and strings are symbols and strings
11:54:56 <doug_16k> what could be different
11:55:10 <gog> dynamic vs static linkage
11:55:11 <gog> lol
11:55:25 <doug_16k> I wouldn't laugh
11:55:43 <doug_16k> you are making a distinction without a difference
11:56:04 <doug_16k> :)
11:56:21 <gog> are you linking with -Bsymbolic?
11:56:32 <gog> or -shared?
11:56:55 <doug_16k> the kernel modules are shared. the kernel is --export-dynamic.
11:58:30 <doug_16k> what were you going to do with symtab if nothing is dynamic?