<gog>
that's sort of solving it by hand in a very roundabout way
nyah has quit [Ping timeout: 272 seconds]
dude12312414 has quit [Ping timeout: 240 seconds]
mahmutov has quit [Ping timeout: 245 seconds]
gog has quit [Ping timeout: 272 seconds]
lainon has quit [Remote host closed the connection]
Coldberg has joined #osdev
C-Man has quit [Ping timeout: 256 seconds]
pretty_dumm_guy has quit [Quit: WeeChat 3.4.1]
srjek has quit [Ping timeout: 240 seconds]
asocialblade has joined #osdev
bradd has quit [Remote host closed the connection]
bradd has joined #osdev
jack_rabbit has joined #osdev
knusbaum has quit [Ping timeout: 256 seconds]
rustyy has quit [Ping timeout: 252 seconds]
rustyy has joined #osdev
sprock has quit [Ping timeout: 256 seconds]
sprock has joined #osdev
mahmutov has joined #osdev
diamondbond has joined #osdev
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
diamondbond has quit [Ping timeout: 272 seconds]
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
diamondbond has joined #osdev
xenos1984 has quit [Quit: Leaving.]
diamondbond has quit [Ping timeout: 256 seconds]
xenos1984 has joined #osdev
ThinkT510 has quit [Quit: WeeChat 3.4.1]
ThinkT510 has joined #osdev
the_lanetly_052 has joined #osdev
mahmutov has quit [Ping timeout: 256 seconds]
Jari-- has quit [Ping timeout: 260 seconds]
the_lanetly_052 has quit [Ping timeout: 272 seconds]
mlombard has quit [Ping timeout: 240 seconds]
terminalpusher has joined #osdev
Coldberg has quit [Ping timeout: 260 seconds]
ThinkT510 has quit [Ping timeout: 260 seconds]
ThinkT510 has joined #osdev
C-Man has joined #osdev
gdd has quit [Ping timeout: 260 seconds]
elastic_dog has quit [Ping timeout: 252 seconds]
elastic_dog has joined #osdev
GeDaMo has joined #osdev
elastic_dog has quit [Quit: elastic_dog]
elastic_dog has joined #osdev
terminalpusher has quit [Remote host closed the connection]
nyah has joined #osdev
_xor has quit [Quit: WeeChat 3.4]
Burgundy has joined #osdev
gdd has joined #osdev
gog has joined #osdev
the_lanetly_052 has joined #osdev
<klange>
Another clone spam on my os repo... what the heck is happening...
<nomagno>
klange: what forge are you using?
albertobasaglia has joined #osdev
albertobasaglia has quit [Remote host closed the connection]
albertobasaglia has joined #osdev
<albertobasaglia>
sad
<klange>
forge? You mean like upstream hosting site? This is Github. I try, but generally fail, to keep things updated on a few sites.
albertobasaglia has quit [Client Quit]
<klange>
Normally I see half a dozen clones a day on the traffic report, and most of those are automated tools like the CI pipeline.
<klange>
On the 15th, and now again today, I'm seeing 700+.
<klange>
And no increase in 'unique cloners', so it's probably one source clone hundreds of times for... who knows what reason.
<bauen1>
^ why would you even do that ?
<j`ey>
stress test github :P
<nomagno>
That doesn't seem like a huge issue
<nomagno>
What if they're trying to simulate monkeys editing the project and see how close it gets to Hamlet?
<kingoffrance>
one day you'll find some remote rainforest village, where they standardized on ponyos
<klange>
this is the main repo, not the pony one, and they wouldn't need to make hundreds of git clones for that ;)
dude12312414 has joined #osdev
srjek has joined #osdev
CaCode_ has joined #osdev
<zid>
debugging a build script and happening to be doing it against your repo
mahmutov has joined #osdev
CaCode_ has quit [Quit: Leaving]
arcadewise has joined #osdev
<arcadewise>
Hi! Newbie here. I'm working through Meaty Skeleton, and I've run into an issue when trying to compile the kernel. Everything seems to be going good, then I hit this error: `/opt/homebrew/opt/i686-elf-binutils/bin/i686-elf-ld: cannot find -lk: No such file or directory`
<clever>
what args did you run ld with?
<arcadewise>
Well, it looks like it's running gcc, which is confusing, but here's what make says: `i686-elf-gcc --sysroot=/Users/arc/projects/stuttgart/meaty-skeleton/sysroot -isystem=/usr/include -T arch/i386/linker.ld -o myos.kernel -O2 -g -ffreestanding -Wall -Wextra arch/i386/crti.o arch/i386/crtbegin.o arch/i386/boot.o arch/i386/tty.o kernel/kernel.o -nostdlib -lgcc -lk arch/i386/crtend.o arch/i386/crtn.o `
<clever>
you have a `-lk` in that arg list
<clever>
that tells it to search for either libk.a or libk.so
<clever>
and then link to that library
<clever>
does such a file exist?
terminalpusher has joined #osdev
<arcadewise>
Ohhh it looks like macOS is messing with me
C-Man has quit [Ping timeout: 256 seconds]
matrice64 has joined #osdev
rustyy has quit [Quit: leaving]
srjek has quit [Quit: Leaving]
terminalpusher has quit [Remote host closed the connection]
the_lanetly_052_ has quit [Remote host closed the connection]
the_lanetly_052 has quit [Remote host closed the connection]
asocialblade has quit [Changing host]
asocialblade has joined #osdev
the_lanetly_052_ has joined #osdev
the_lanetly_052 has joined #osdev
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
<papaya>
trying to migrate my kernel from 32-bit to 64-bit today, hoping I haven't bit off more than I can chew
<geist>
you had written a lot of assembly right?
<geist>
you'll have a lot of convert
<papaya>
a fair amount
Burgundy has joined #osdev
<geist>
though a fair amount of 32bit asm will generally work without modification on 64bit,but that actually is tricky because it seems deceptively simple
<geist>
also your interrupt/exception code you'll have to redo from start, things like pusha dont exist on 64bit
<papaya>
I've made enough modifications that it will at least compile and link tho now I cant find my multiboot header^^;
<geist>
i'm all for it, but i'd like to nudge you in the direction of writing less assembly
<papaya>
I know I manually changed it out for individual pushes of 64-bit regs
<geist>
you *really* need to know the 64bit ABI too, which registers are saved/trashed and how args are passed
<geist>
it's a lot more complicated than x86 32bit
<geist>
print it oit and paste it on the wall, it's hard to remember offhand
<papaya>
yea I assume the C calling conventions on x86 wont work here
<papaya>
there's a lot more parameter passing via register I think?
<papaya>
I did read about the red-zone issues with kernel space and I made sure to build my cross compiler to account for that
<geist>
yep. first 6 args via registers now
<geist>
and yep. red zone
<geist>
you'll need to set -mno-red-zone when compiling kernel stuff
<papaya>
but, grub2 should be able to find a multiboot header in a 64-bit elf file right?
<geist>
also yay r8-r15! more regs
<papaya>
yea its in my linker flags
<gog>
grub can't use 64-bit elf's i think
<gog>
although i may be remembering wrong
<papaya>
I thought it was 64-bit elf aware just cant start long mode
<papaya>
like I know the bootstrap code has to be 32-bit
<geist>
right, grub wpnt directly load 64bit ELF i think, but you can still put in a multiboot header that loads it as if it was 32bit
<gog>
idk for sure but i think so
<geist>
and then it branches into it as 32bit
<geist>
so you'll have to complete the trampoline to 64bit
<gog>
honestly i'd recommend just using UEFI and writing a little ELF loader yourself
<gog>
feel free to crib from mine
<papaya>
the 32-bit bootstrap code is still inside the same elf binary tho is it not?
<papaya>
gog: but you use efi and I'm not atm ^^;
<geist>
if that;s how you want to do it, yes. that's how you do it
<gog>
i mean you can do that
<papaya>
geist: is it common to have separate 32-bit and 64-bit binaries for this
<geist>
for exactly what?
<geist>
(want to make sure i'm answering yes/no to the right thing)
<papaya>
bootstrapping into longmode
<gog>
you can have a shim in a 32-bit elf and the kernel loaded as agrub module
<geist>
nah, it's generally easy to just have a little shim at the start
<papaya>
thats what I thought, I kept BITS 32 in my boot file with the header and bootstrap (nasm)
<gog>
i agree that it's easy but different things are different and should be in different files :p
<bslsk05>
github.com: lk/start.S at master · littlekernel/lk · GitHub
<papaya>
I'm building it into a single binary but now it doesnt find the multiboot header lol
<geist>
multiboot header that points to a piece of code that trampolines into 64bit mode
<geist>
yah i have two whole directories here, one for 32 one for 64
<geist>
since it's pretty different at this level
<papaya>
I think BITS 32 is the nasm equiv of gas .code32 ?
<geist>
probably
<papaya>
I just... really dislike att syntax
<geist>
and at line 200 it switches to 64bit mode
<papaya>
tho it seems a lot of ppl are using gas instead of nasm
<geist>
the main annoyance with getting into 64bit is you have to use page tables to do it
<geist>
since turning on paging is a requirement for long mode
<geist>
that code just sets up an identity map of the first 64GB of physical space
<geist>
with the assumption that the code is probably loaded there and thats enough to get into the kernel which will then set things up further
<papaya>
I've done some tinkering with paging in 32-bit space
<geist>
well, for better or worse you need to at least set up an identity map
asocialblade has quit []
Matt|home has quit [Ping timeout: 240 seconds]
<clever>
that identity map also assumes that your 64bit entry-point is PIC
<geist>
or you just link the kernel to run at a fixed address in physical
<geist>
that's why i said 'at least'
<clever>
assuming you know where ram will be
<clever>
and can get the bootloader to load you to that addr
<geist>
clever: we're talking about x86-pc here
<geist>
different rules from what you may be used to
<clever>
yeah, the whole upgrading from 32 to 64bits is backwards compared to arm
<geist>
for what papaya is doing, you're literally telling multiboot where to load your binary, and thus you can rely on it being in a particular spot (or not loaded)
<clever>
ahh, so you can be loaded to the addr you wanted, if that addr is ram
<papaya>
btw you suggested I write less assembly but most my assembly is ISR or descriptor tables, etc... is it really a good idea to try to do these in C? what portions do you feel should or shouldn't be in asm?
<geist>
right, and ram is implicitly starting at 0, etc
<geist>
papaya: i disagree, most of your assembly seems to be things that can be written in C
<geist>
like your keyboard driver, stuff dealing with a circular buffer, etc
<clever>
isnt the first 64kb of ram kind of special though?
<clever>
where bios keeps state
<geist>
clever: yes.
<papaya>
geist: so you think I'm doing too much in my ISR
<geist>
there are places you dont tell multiboot to load to. generally avoid anything < 1MB, etc
<geist>
papaya: yes.
<geist>
more importantly you're writing the entire ISR in asm instead of a simple stub that gets you into C
<geist>
where you write the meat of your ISR
<geist>
usually systems just implement the register saving/restoring in asm, then branch to equivalent C (or whatever high level language you want) code
<geist>
so that you end up with only hundreds of lines of asm in an entire OS, just the stuff you can't avoid doing in asm
<papaya>
I was (perhaps wrongly) under the impression that doing anything in ISR with C was not a good idea
<geist>
nope.not at all
<papaya>
assume you mean nope as in I was mistaken
<geist>
at the minimum you ant to take that pusha/etc stuff you have and make a macro out of it in asm so you dont have to type it in more than one
<geist>
since it's extremely error prone
<papaya>
I see, well now I know... should make things easier at the least
<geist>
but see if yo uwrite the keyboard specific ISR code in C for example it would intrinsically work on x86-32 or x86-64
<geist>
thus you only end up with arch-specific first level handler code, and that codes' job is to get registers saved and into a C environment
<geist>
(note when i say C i mean 'C like languages')
<clever>
what about how much the ISR asm should save?
<geist>
it *does* mean you'll have to implement some inline assembly to wrap the in/out instructions so you can do that in C, but that's easy to do and there are tons of examples
<geist>
clever: depends on the arch. extremely arch specific
<clever>
do you prefer a full save/resotre of all registers? or save the minimal (abi clobbered) and let the function proloque's in c preserve the rest?
<geist>
depends on the arch, for the most part. in general the latter, but the former may be just as simple, and easier to debug
<clever>
in theory, both should work, if gcc correctly saves/restores the non-clobbered registers
<clever>
exactly
<geist>
depends on if there's actual real performance gains
ThinkT510 has quit [Ping timeout: 272 seconds]
<geist>
arm64 LK i think still does the latter, but eventually we moved zircon to just doing the full save so it was a consistent iframe
<papaya>
well I have in and out functions implemented in asm using C calling convention and exported to C
<geist>
papaya: that works too, just make sure yo uget the calling convention right
<clever>
the VPU LK port is doing a full save, because i'm sharing code between fatal exceptions and IRQ's
<papaya>
I have it right, for 32-bit at least, obv will need to change it for 64
<clever>
and the asm doesnt entirely know if the full frame is needed
<clever>
but saving less is an option for improving performance
<geist>
right
ThinkT510 has joined #osdev
ThinkT510 has quit [Read error: Connection reset by peer]
<geist>
on something like riscv it's hard to know, since *all* exceptions and irqs come in via a single entry point
<geist>
but arm64 for example at least has separate vectors for irq/fiq so you can save less there if you want
<clever>
VPU is the reverse, every single exception and irq can have its own unique entry-point
<geist>
x86 of course has 256 vectors so you can just macroize it to save different amounts if you want
<clever>
and i'm just choosing to share one
<geist>
yah that's what i'd recommend, pointing them all at the same routine
<geist>
papaya will get to this soon too
<geist>
the new intel FRED stuff if they ever implement it looks much more like arm/risc, iirc
<clever>
with how LK does irq's, i couldnt really point the vector table directly into a registered handler
<geist>
i think they collapse everything to one or a few entry points
<clever>
because the optional reschedule at the end complicates matters
<geist>
yep
<geist>
arm cortex-m has that problem, and i have to resort to just requiring all implemented exception handlers *must* call this one routine at the exit
<geist>
which does the schedule stuff
<clever>
but that kind of changes the api for a lot of things, like timer callbacks
<geist>
anyway, gotta go. visiting bay area this week, about to go visit the computer history museum
<geist>
haven't been here in years, and it's now open again on weekends