<ddevault>
this bootloader bug that I'm working on is incredibly annoying
<zid`>
Maybe stop working on the bug and start working on the fix
<ddevault>
thanks
warlock has quit [Ping timeout: 260 seconds]
Nixkernal has joined #osdev
bauen1_ has quit [Ping timeout: 252 seconds]
<geist>
i second what zid says: link to elf and then use an objcopy step to flatten it to a binary
<geist>
then you have the elf that you can use for debugging, disassemby, etc
<Ermine>
Also some debugging probes understand elf and can flash elfs straight away
<geist>
yep and most of the architectures that aren't x86 understand it with -kernel on qemu
<geist>
you can just load your elf directly
<nikolar>
Can't you do -kernel with x86 too
<zid`>
no
<zid`>
it tried to linux boot protocol and shit it
<zid`>
tries*
<nikolar>
Ah
<zid`>
then multiboot, then gives up and complains about an OVH header or something
<geist>
it's complicated, depends on 32 vs 64 and i forget the precise details
<geist>
yeah
<zid`>
because of the way the errors fall through
<geist>
but on pretty much all the other arches, since there's no multiboot either either parse it as elf, or fall through an interpret as .bin and load it to some fixed address
<bslsk05>
'Battleme - Hey Hey, My My (Sons of Anarchy S03E13)' by BoonesFrry (00:02:56)
gsekulski has joined #osdev
<Ermine>
No, I'm too genz for that
gsekulski has left #osdev [#osdev]
gog has quit [Quit: Konversation terminated!]
<Ermine>
Is hardware task switching widely used, or do people prefer software one?
MrCryo has joined #osdev
rustyy has quit [Ping timeout: 240 seconds]
xenos1984 has quit [Ping timeout: 260 seconds]
<Halofreak1990>
the software one is preferred, being more flexible, and also easier to translate to other platforms
osdev199 has joined #osdev
oldgalileo has joined #osdev
node1 has quit [Quit: Client closed]
spare has quit [Remote host closed the connection]
<osdev199>
Hello, I'm getting the invalid opcode (vector nr. 6) exception on executing the bash shell (a compiled 64-bit linux elf binary for x86-64 arch) in my os on my real machine. The `rip` is outside the loaded segments of the bash shell. How to debug this? Thanks.
oldgalileo has quit [Ping timeout: 260 seconds]
xenos1984 has joined #osdev
gog has joined #osdev
rustyy has joined #osdev
netbsduser has quit [Ping timeout: 240 seconds]
netbsduser has joined #osdev
gog has quit [Quit: byee]
gog has joined #osdev
osdev199 has quit [Remote host closed the connection]
xFCFFDFFFFEFFFAF has joined #osdev
<Ermine>
This guy got userspace but didn't make a toolchain for his os?
<geist>
Ermine: re: hardware tasking. it's never used on anything modern
<geist>
x86-64 doesn't even support it for 64bit contexts
Halofreak1990 has quit [Ping timeout: 268 seconds]
<Ermine>
Okay
<Ermine>
Thank you
<Ermine>
Was that failed attempt to speed up context switches?
<GeDaMo>
Did they copy it from the Vax? :P
masoudd has quit [Quit: Leaving]
<geist>
GeDaMo: probably
<geist>
though the way x86 does it is a bit more overengineered than the way vax does it. i think it was more of a derivative of the axp432 work they were doing
<geist>
but that may be closer to vax. dunno the details of that
<geist>
Ermine: it wasn't so much failed, as it fell out of favor over time, and by the time 64bit stuff was invented there was no real need to use it
<geist>
and modern x86s (last 25 years or so) just implement it in microcode, slowly
<Ermine>
Oh. If it really helped with context switching performance, I'd rely heavily on this in microkernel systems
eddof13 has quit [Quit: eddof13]
<geist>
yah it does not. a few years back i wrote some test case to actually measure it (for 32bit protected mode, since it doesn't exist for 64bit) and it was hecka slow on modern machines
<geist>
like many times slower than just doing it manually
Halofreak1990 has joined #osdev
goliath has joined #osdev
<nikolar>
What about the processors it wasn't mean to be used on
navi has joined #osdev
eddof13 has joined #osdev
foudfou has quit [Quit: Bye]
foudfou has joined #osdev
oldgalileo has joined #osdev
xFCFFDFFFFEFFFAF has quit [Remote host closed the connection]
oldgalileo has quit [Ping timeout: 255 seconds]
fluix has quit [Ping timeout: 260 seconds]
gbowne1 has joined #osdev
<geist>
hmm what do you mean processors it wasn't meant to be used on?
<geist>
it's a feature all modern x86s still have, it just was never extended to support full 64bit mode
<geist>
so to use it you need to be running 16 or 32bit OS code
<nikolar>
Eh typo
<nikolar>
It *was*
<nikolar>
Like early 32 bit cpus that introduced it
<mjg>
not that even something as simple and *common* as function prologue/epilogue had instructions which were slower than spelling it out
<mjg>
note*
<mjg>
so i would not be particularly surprised if magic task switching was also slow af
xFCFFDFFFFEFFFAF has joined #osdev
<geist>
well, so for example i wrote some code a few years back that used it on a proper 386sx
<geist>
it was predictably about as fast as doing the equivalent instructions, except it has the added ability to direct context switch between two complete cr3 contexts
<nikolar>
So it was no worse
<geist>
so you can directly switch between two user processes, which is not something you can do
<geist>
it was no worse for sure. maybe a bit faster since it required less instructions
<zid`>
yay new headphones
<zid`>
Nice and tight again, unlike my bent-out and broken-ass previous pair
<geist>
however it also is not as flexible. the TSS task switching stuff always reloads all registers, including all of the segments
<nikolar>
Interesting
<geist>
and on older hardware (newer too really) loading a segment register is pretty slow (was like 30 cycles on a 386) beause it has to do a fetch from the GDT/LDT and a bunch of microcode to validate the contents
<geist>
which was already a lot of the time. 6 segment registers + 30 cycles a piece or so
<geist>
so iirc the whole thing was like 300 cycles. i then wrote my own softeare code to do most of the same thing and since i didn't need to reload all the registers it was about that much faster
<geist>
so interestin i then ran it on like a skylake and a bulldozer class machine (this was a few years back i wrote this code) and it was even worse. like 1000 cycles. but that's not surprising, because modern cpus they dont bother optimizing it
<geist>
i'm sure it drops into some sort of slow microcode path with a full state dump
<nikolar>
Yeah guess it was never used widely enough to get proper support
<zid`>
Probably makes the verification people's job a lot easier
<zid`>
if it's done in a little microcode VM, rather than silicon
<bslsk05>
github.com: 3x86/x86/tss.c at c5650a4f867975319833b74006f9c94d2e21c389 · travisg/3x86 · GitHub
oldgalileo has joined #osdev
<geist>
was just trying to set things up enough to actually do a task switch
<geist>
at the end of the day switching tasks is just a ljmp to a TSS segment though, kinda neat
<nikolar>
Yeah sounds like it
<geist>
re: the questioa bout did they copy fro VAX. not really. the VAX hardware task switching is in some ways simpler and easier to use, since it's really just a pair of instructions: svpctx and ldpctx
<geist>
you load a control register with a pointer to the hardware state structure and do a save, load a new pointer, load
<geist>
very straightforward. it just slams the state of the cpu down in a struct
<bslsk05>
github.com: lk/arch/vax/include/arch/vax.h at vax · littlekernel/lk · GitHub
oldgalileo has quit [Ping timeout: 268 seconds]
fluix has joined #osdev
<geist>
it's like intel copied a lot of details from VAX but filtered them through this object oriented way of thinking that i think was permeating the axp432 at the time
<geist>
so everything needed a handle to a thing (segments) and you basically treated it like an opaque object
sham1 has quit [Ping timeout: 264 seconds]
<geist>
and hardware always has pointers to tables that contain data, instead of just pointers to the data
<xFCFFDFFFFEFFFAF>
whut
<xFCFFDFFFFEFFFAF>
what this stackter is saiynb and how much
fluix has quit [Remote host closed the connection]
xFCFFEFFFFFFFFFF has joined #osdev
xFCFFDFFFFEFFFAF has quit [Ping timeout: 264 seconds]
<Ermine>
a bunch of microcode to validate the contents <-- so invalid table will trigger GPF?
<geist>
yah
<Ermine>
Does processor validate page tables in the same way?
<mjg>
was dos using the thing?
<Ermine>
it's protected mode stuff, dos isn't
<mjg>
aight, then was windows 3.x using the thing?
<mjg>
(or is that sucker not protected either?)
<nikolar>
Wonder what the world would look like if we were running axp432 instead of x86
fluix has joined #osdev
<Ermine>
it was protected afaik, so answer is probably yes
<Ermine>
And I think same goes for 9x
<mjg>
nikolar: i wonder how the world would look like if ibm rolled with unix early on
xFCFFEFFFFFFFFFF has quit [Quit: 0xC0230002 STATUS_NDIS_CLOSING]
<nikolar>
Maybe we'd all be running power or s390
<GeDaMo>
There were other x86 multi user / tasking systems around, maybe some of them used it
xFCFFDFFFFEFFFAF has joined #osdev
<Ermine>
book on VxD programming discusses IDT/GDT stuff quite in-depth, so that's why I'm thinking why they used gdt heavily
<Ermine>
But they could mix it with paging as well, I guess