TkTech has quit [Read error: Connection reset by peer]
TkTech8 has joined #osdev
Compy has quit [Remote host closed the connection]
m5zs7k has quit [Ping timeout: 272 seconds]
m5zs7k has joined #osdev
smach has joined #osdev
joe9 has quit [Ping timeout: 248 seconds]
joe9 has joined #osdev
ZipCPU_ has joined #osdev
ZipCPU has quit [Ping timeout: 260 seconds]
ZipCPU_ is now known as ZipCPU
elastic_dog has quit [Ping timeout: 246 seconds]
elastic_dog has joined #osdev
bauen1 has quit [Ping timeout: 252 seconds]
bauen1 has joined #osdev
bauen1 has quit [Read error: Connection reset by peer]
LostFrog has joined #osdev
PapaFrog has quit [Ping timeout: 248 seconds]
bauen1 has joined #osdev
eroux has quit [Ping timeout: 272 seconds]
xenos1984 has quit [Read error: Connection reset by peer]
xenos1984 has joined #osdev
smach has quit []
aejsmith has quit [Remote host closed the connection]
aejsmith has joined #osdev
GeDaMo has joined #osdev
eroux has joined #osdev
bauen1 has quit [Ping timeout: 260 seconds]
bauen1 has joined #osdev
bauen1 has quit [Ping timeout: 260 seconds]
bauen1 has joined #osdev
wand has quit [Remote host closed the connection]
gxt has quit [Remote host closed the connection]
wand has joined #osdev
gxt has joined #osdev
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
vdamewood has joined #osdev
Arthuria has joined #osdev
escatrag has joined #osdev
<escatrag>
Hello everyone, i am currently building a small kernel for fun, and have trouble getting elf infos from grub (legacy). I can get the memory map, and others infos, but not elf header(s). The ELF structure ```multiboot_elf_sec->addr = 0x10144```, but no datas seems to be there when looking with GDB. Is there infos or offset i am missing ? The kernel
<escatrag>
start at 0x100000, if that can help. Thanks !
<zid>
what elf info?
<zid>
grub doesn't boot elf, it boots multiboot
<zid>
it's only there if you also made your multiboot image an ELF, and it's.. where you put it inside the multiboot image
<zid>
nothing to do with grub
<zid>
for me that's just "byte 0", because I use an ELF with a multiboot header inside it
<bslsk05>
www.gnu.org: Multiboot Specification version 0.6.96
<escatrag>
What i find weird is that the elf flag is enabled, is should mean the infos are available and valid no ? I get the correct number os sections (27), correct size (40), the only info seeming wrong is the address...
<zid>
I assume that header is for multiboot2
<zid>
I've never used it
<escatrag>
No, it is multiboot legacy
<zid>
okay bye
<escatrag>
X)
heat has joined #osdev
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
Arthuria has quit [Ping timeout: 252 seconds]
Dyskos has quit [Quit: Leaving]
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
[itchyjunk] has joined #osdev
bauen1 has quit [Ping timeout: 260 seconds]
bauen1 has joined #osdev
heat_ has quit [Remote host closed the connection]
heat_ has joined #osdev
srjek|home has joined #osdev
heat_ is now known as heat
nyah has joined #osdev
bauen1 has quit [Ping timeout: 260 seconds]
bauen1 has joined #osdev
<heat>
slub is actually kinda neat
<heat>
they stop with the magazines and just keep a dedicated partial slab list for each cpu
<zid>
so it's belt felt instead?
<zid>
fed*
<zid>
My allocator is belt fed, thinking about it, it's just a list
<zid>
you unhook a page and BLAM, shoot it at a communist
<zid>
linux for reference is approximately 1/400th the size
xenos1984 has quit [Ping timeout: 248 seconds]
tacco has joined #osdev
<geist>
Yah but macOS is > linux
<gog>
lexically maybe
<gog>
technically too
<gog>
yeah
<zid>
linux is catching my 7 up, going to have to switch in a couple years
<geist>
7 is a good vintage. Windows7was pretty good
<zid>
w10/w11 do precisely no more things, but do a lot of anti-things
<zid>
unless you want dx12
<zid>
The only dx12 game I've wanted to play is elden ring but my gpu isn't good enough anyway so whatever
<gog>
you want my computer zid i'm gonna buy a new one again
<zid>
I want urdimms and a gpu and a new monitor
<zid>
everything else is okay
<gog>
i can't help with that sadly
<zid>
I like my monitor but it's dying, and I don't wanna risk doing surgery without a backup
gildasio has quit [Ping timeout: 255 seconds]
gildasio has joined #osdev
epony has quit [Remote host closed the connection]
<heat>
gog, send em compter
<zid>
computerbombing, new sport
xenos1984 has joined #osdev
elastic_dog has quit [Ping timeout: 246 seconds]
elastic_dog has joined #osdev
<heat>
no, not u, me
<heat>
semd me computing
<heat>
i need it for compile c++
<zid>
imagine being so bad at keyboard you say the opposite of what you mean
<heat>
shut up zed
kof123 has joined #osdev
srjek|home has quit [Ping timeout: 248 seconds]
epony has joined #osdev
heat_ has joined #osdev
heat has quit [Ping timeout: 252 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
dude12312414 has joined #osdev
scoobydoo_ has joined #osdev
zid has quit [Remote host closed the connection]
scoobydoo has quit [Ping timeout: 260 seconds]
scoobydoo_ is now known as scoobydoo
puck has quit [Excess Flood]
puck has joined #osdev
smach has joined #osdev
<geist>
zeds dead, baby
zid has joined #osdev
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
heat_ has quit [Read error: Connection reset by peer]
heat has joined #osdev
heat_ has joined #osdev
heat has quit [Ping timeout: 252 seconds]
GeDaMo has quit [Quit: I'm going to show these people something you don't want them to see. I'm going to show them a world without you.]
bgs has quit [Remote host closed the connection]
heat has joined #osdev
heat_ has quit [Read error: Connection reset by peer]
smach has quit [Quit: No Ping reply in 180 seconds.]
smach has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
smach has quit []
smach has joined #osdev
<heat>
how can oopsing (as in linux oopsing) ever be safe?
<geist>
i've personally never figured this out
<geist>
tis why zircon has no such concept. we have an OOPs but all it is is basically print a formatted error message with a stack trace, and continue
<geist>
whereas i think the linux oops actually tries to stop the thread or whatnot
gildasio has quit [Remote host closed the connection]
<heat>
linux oops kills your process
<geist>
and shoots your dog
<heat>
but it oopses for real crashes like null dereferences
<heat>
getting inconsistent state doesn't sound like the greatest idea
<geist>
indeed. i've always been 'brought up' with the idea that any sort of assert or panic level failure in the kernel is fatal, period. hard stop
<heat>
they're even catching crashes in EFI runtime services these days
<heat>
like ?????
<mrvn>
I think the idea is that the thread that does the oopsing will have locks on the subsystems that are inconsistent and therefore keeps them locked down. Whatever is left unlocked is assumed to be more or less functional.
<heat>
i assume that if you oops while holding locks, you die
<heat>
unless you want really fun system hangs
<mrvn>
heat: I don't think the threads get killed, just paused.
<heat>
they do get killed
<mrvn>
the kernel threads?
<heat>
processes at least
gildasio has joined #osdev
<heat>
but if you're holding locks, the only valid approach is to panic
<mrvn>
userspace you can clean up but how would the kernel know what locks the kernel thread holds and such?
<heat>
^^
<mrvn>
And why panic just because $obscure-driver oopses. Just keep that part locked down.
<geist>
yeah you could for example run the drivers in some sort of separate container
<geist>
maybe with a different memory map
<heat>
yeah
<heat>
some sort of small kernel
<mrvn>
now that would be a microkernel, which makes the whole oopsing thing much saner.
<heat>
what's a microkernel
<heat>
is this already a thing?
<mrvn>
welcome to the 21st century
<heat>
thanks
<mrvn>
Linux has several macros for kernel bugs from WARN_ON to full blown "ieee, scheduling in interrupt. Not syncing"
<heat>
spoiler: nothing syncs
<heat>
anyway jokes aside
<heat>
"Just keep that part locked down." is the wrong vibe
<heat>
not only do you need to diagnose your OOPS, you need to diagnose general system hangs
<mrvn>
if your kernel gets big with many contributors that becomes a viable solution
<mrvn>
If nothing critical is hit your kernel just keeps running and you can diagnose the problem. If something critical is locked then everything stops, just like if you panic.
<heat>
oops under a lock *is* critical
<mrvn>
heat: only to the lock
<heat>
you cannot ever know what lock you were holding
<mrvn>
And what do you suggest to do? Release the lock in an inconsistent state?
<heat>
panic()
<mrvn>
why? Just because the printer driver has a it's lock locked?
<zid>
I mean, same way segfaults are fatal to userspace code except sometimes you just install a signal handler for it and move on
<zid>
because you know what you were doing
<zid>
if the system is stable after the efi crashes, you just found out it's crashy efi and use another path, shrug
bauen1 has quit [Ping timeout: 260 seconds]
<zid>
it's unpredicted crashes that are fatal
<heat>
mrvn, yes.
<mrvn>
heat: that just makes it harder to debug the problem. Can't look at the dmesg for example.
<heat>
a panic stuffs all that shit into an efi variable
<heat>
what if you crashed holding the log lock?
<heat>
oopsie?
<mrvn>
Oh great. so it will fill the efi storage and brick the laptop :)
<heat>
dmesg just hangs
<heat>
this is not new
<heat>
your linux does it too
<mrvn>
heat: dmesg doesn't hang when the printer driver has it's mutex locked.
<heat>
dude shut up with the printer driver
<heat>
it's a BUG
<heat>
if you think handling a page fault by just "oh no! anyway", more power to you
<heat>
it's clearly not safe, but have fun doing that in your userspace programs too
<mrvn>
sure. a BUG in some random component of the kernel. Chances are that it isn't anything critical because those parts are more tested
<mrvn>
heat: do you kill all your userspace programs just because one process does a segfault? That's basically the equivalent.
<zid>
I've seen the userspace thing in production code when probing dlls, a lot
<heat>
it's absolutely NOT
<heat>
processes are isolated
<heat>
there's 0 isolation in the kernel
<zid>
/* This is crashy on certain versions but windows has no dll versioning so.. catch the segfault and pretend we didn't see this dll */
<mrvn>
heat: but plenty of separation. Sure it's a gamble that nothing got corrupted in another subsystem but that's one linux takes.
<heat>
there's between 0 and 0.2 separation in the kernel
<mrvn>
0 would mean that every line of code modifies every kernel memory. fun
<heat>
and it can, and it does
<heat>
linux is not modular
<heat>
it has modules, but it's definitely not modular
<mrvn>
Experience shows that plenty of BUG_ON cases will just add a nice dump to the kernel log and the system continues minus the affected subsystem, if even that.
<mrvn>
It might not be safe and you might not like it but it works pretty well for linux.
<heat>
BUG_ON is not an oops
<heat>
they are two different things
<heat>
BUG oopses, but BUG is explicitly called
<mrvn>
so you only consider null pointer accesses real oopses?
<heat>
any kernel trap oopses
<heat>
those are the real scary oopses
<heat>
any line can oops, wonderful!
<zid>
IRQ_LESS_OR_NOT_EQUAL
<mrvn>
I think it's rather irrelevant if the oops is triggered by the hardware detecting a fault or the software and calling BUG. Somethings gone terribly wrong either way.
<mrvn>
.oO(ever had an oopse on a NOP?)
<mrvn>
On m68k I had to debug a crash where it turned out the icache wasn't flushed so the executed code and memory content where totaly different.
srjek|home has joined #osdev
elastic_dog has quit [Ping timeout: 248 seconds]
elastic_dog has joined #osdev
gildasio has quit [Ping timeout: 255 seconds]
gildasio has joined #osdev
spikeheron has quit [Quit: WeeChat 3.7]
bauen1 has joined #osdev
gxt has quit [Write error: Connection reset by peer]