<junon>
anyone know the typical config/env var name for specifying the linker? (ld)
<junon>
e.g. CC is for c compiler, CXX is for c++ compiler. Which one specifies `ld` typically?
<junon>
LINK? LINKER? LD?
<Mutabah>
LD is what I use
<junon>
okay
<junon>
my only reservation about that name is due to MSVC's link.exe but I think it's fine in this case.
<moon-child>
I usually use 'LD' to point to the 'ld' binary, but CCLD' for the c compiler when it is used to link (usually just the same as CC)
<junon>
yeah I might add a differentiator for CCLD or something. Right now where `E` and `C` refer to the environment and then the build config respectively, I have `C'CC' or E'CC' or DEFAULT_COMPILER` for the executable link steps. I might change it to `C'CCLD' or E'CCLD' or C'CC' or E'CC' or DEFAULT_COMPILER`.
<junon>
But haven't run into a case where I need that yet.
<junon>
But now need to add `ld` support to get the kernel's link script working after migrating from CMake to my own build system.
CaCode has quit [Read error: Connection reset by peer]
CaCode has joined #osdev
<junon>
are there other common ld names other than `ld` and `lld`?
<junon>
and ofc msvc's link.exe but that's not relevant, just curious about linux
c2a1 has quit [Ping timeout: 264 seconds]
c2a1 has joined #osdev
<moon-child>
lld, bfd, gold, tcc ...
<junon>
never seen bfd, what's that?
<moon-child>
primary binutils linker
<junon>
Forgot about gold, is its CLI based on GNU's or is it its own thing? e.g. lld has ld.lld which runs in GNU compat mode.
<junon>
oh I have it installed, neat. I can test it myself, nvm
<moon-child>
i mean, probably you're building your own cross toolchain, so you control that environment, no? So you can choose whichever you want
<junon>
moon-child: I'm writing a build system
<junon>
I want to support each of the linkers ideally.
<junon>
I run `--version` on them to determine which CLI variant I should use when translating build options to CLI options when doing rule generation.
<moon-child>
oh
<moon-child>
use cc to link
<junon>
for libraries and executables, yes.
<junon>
for scripts it doesn't work as well IME
<junon>
e.g. for linking a kernel with an LD script.
qookie has quit [Ping timeout: 256 seconds]
<moon-child>
if somebody is using a custom linker script, I think it makes sense to make them specify their own linker command-line
<kingoffrance>
https://en.wikipedia.org/wiki/Binary_File_Descriptor_library When David Henkel-Wallace of Cygnus Support proposed developing the library as a way to open up new business opportunities for the company, Richard Stallman said that it would be difficult; David's response was that it wasn't such a "Big Fucking Deal"
<bslsk05>
en.wikipedia.org: Binary File Descriptor library - Wikipedia
<kingoffrance>
thats BFD -- "Big ******* deal" :D
<junon>
huh neat
<junon>
moon-child: hmm yeah. I don't suppose linker scripts are generally compatible between linkers.
<moon-child>
reasonably compatible. But an obscure use case
<junon>
I'd rather not tie directly to a specific linker though, that's more my issue.
simpl_e has quit [Read error: Connection reset by peer]
simpl_e has joined #osdev
simpl_e has quit [Read error: Connection reset by peer]
simpl_e has joined #osdev
_caveman has quit [Quit: WeeChat 2.8]
sonny has joined #osdev
simpl_e has quit [Read error: Connection reset by peer]
srjek|home has quit [Ping timeout: 245 seconds]
srjek has joined #osdev
simpl_e has joined #osdev
simpl_e has quit [Read error: Connection reset by peer]
sonny has left #osdev [Good Bye]
simpl_e has joined #osdev
simpl_e has quit [Read error: Connection reset by peer]
<geist>
noice
<geist>
never looked into halfnium that much, though i remember talking to the team members a bit when it was owned by google
simpl_e has joined #osdev
simpl_e has quit [Read error: Connection reset by peer]
simpl_e has joined #osdev
simpl_e has quit [Read error: Connection reset by peer]
simpl_e has joined #osdev
simpl_e has quit [Read error: Connection reset by peer]
Spikeheron has quit [Quit: WeeChat 3.3]
dutch has joined #osdev
elderK has quit [Quit: Connection closed for inactivity]
mctpyt has quit [Ping timeout: 256 seconds]
simpl_e has joined #osdev
simpl_e has quit [Ping timeout: 260 seconds]
<geist>
but trying to put together a good type 1 hypervisor for arm64 is one of those things i wanna do some day
<geist>
looks like fun if nothing else. sadly riscv seems to have taken the x86 style kinda in their hypervisor extension
<gorgonical>
It's looking increasingly like I'm gonna have to (get to?) write my own
<geist>
ie, instead of having an run level above supervisor they have a modal switch thing
<gorgonical>
We're targeting hpc and so hafnium is sort of not "quite right"
<geist>
possible LK might be a starting point?
<gorgonical>
I'm not familiar with that one
<geist>
littlekernel, my project
<geist>
in that you can start from a fairly minimum preemptive SMP kernel, run it in EL2 and build a type 1 out of it
<gorgonical>
ah I see
<moon-child>
I can never remember--type 1 hypervisor is the cooperative kind?
<gorgonical>
I always think of it as "Bare metal" vs "hosted"
<geist>
yah, type 1s are kinda out of vogue, and the lines are blurred, but yeah it'd be a specific kernel that explicitly hosts others
<geist>
ESXi is pretty close, as well as probably piles of closed source thigns that have anything to do with IBM hardware
<geist>
being that arm64 has a proper higher level priviledge level, it seems to be naturally suited for a type 1
srjek has quit [Ping timeout: 245 seconds]
<gorgonical>
I don't remember who it was, but they were right; arm64 is way nicer as a virtualization architecture
<gorgonical>
No more "oh shit vmcs_read itself failed and fucked up the error codes, who knows what went wrong???"
<geist>
may have been me, i've been extolling the virtues of it for a while
<geist>
what makes it muddy is there's an extension in v8.1 or .2 that if you enable it causes it to look a bit more like x86
<geist>
*sort of*
<gorgonical>
That's the VHE stuff right?
<geist>
yep
<gorgonical>
It is not pretty, indeed
<geist>
but you see exactly what is for right? it's so you can run a kernel compiled to run at EL1 at EL2
<gorgonical>
right
<geist>
so that a hosted kernel turns into a type 1
<geist>
either it's totally genius or terrible. haven't decided yet
<gorgonical>
wait
<gorgonical>
I understand the words but not what you mean
<gorgonical>
the purpose being that you can e.g. take linux compiled for el1 and use it (kvm or whatever) to host other stuff?
CaCode- has joined #osdev
<geist>
more efficiently, yes
<geist>
w/out VHE you can still take linux and host things, but what happens is the DOM0 (for lack of a better term) still runs at EL1
<geist>
and it has to leave a little trampoline at EL2 that it uses to bounce between its guests. standard practice. is how KVM, etc work
<geist>
w/VHE you can just run the DOM0 linux at EL2, but without recompiling it because it still thinks it's accessing EL1 control registers
<gorgonical>
The idea being that you get to approximately halve the context switches?
<geist>
yah
<gorgonical>
And I guess there's also less hcr_el2 reconfiguring then
<geist>
you avoid a lot of the bounces through EL2
<gorgonical>
Because the dom0 needs a special set of values
<geist>
yah. probably so
<gorgonical>
yeah I see your point. It might be genius
CaCode_ has quit [Ping timeout: 250 seconds]
<geist>
you could *also* link your host kernel (linux, etc) to just run at EL2 without VHE
<gorgonical>
I know I'm late to this party but has anyone seen the quartz64? It intrigues me because it says it has an "embedded risc-v processor" but I don't know what that means
<geist>
though i think there may be some other features that are enabled with VHE. I forget precisely if you can easily host a EL0 under EL2 directly (ie have user space) without VHE
<geist>
possibly some aux control processor is riscv. fairly common nowadays
<geist>
side note: cortex-a55 is i believe v8.2 so it probably has VHE
<geist>
though approximately as fast as a cortex-a53 (dual issue, in order, etc)
<gorgonical>
I swear I just read this like two days ago. Did I hallucinate reading that??
<geist>
well, if it did have some sort of extra riscv i wouldn't be surprised
<gorgonical>
well apparently I imagined that
<gorgonical>
pine is planning to build a risc-v board, which would be dope
<gorgonical>
You know I was checking it out on cpubenchmark and it looks like the rk3566 is actually just as fast as my laptop
<gorgonical>
Poor beast is really showing its age
<geist>
heh
<geist>
if it weren't that web sites are getting more and more complicated, and i tend to leave more and more tabs open i'd generally just say anything in the last 10 years is good enough for me
<geist>
but alas, the march of more and more crap going electron and web based...
<gorgonical>
indeed. Every day I have at least one instance where I rage that my phone completely locks up trying to visit a mundane website. My phone is not a flagship, but it's still a modern smartphone
<geist>
yah it's kinda like being forced to install newer and newer and slower versions of your favorite apps constantly, since the app itself is the pile of js and whatnot that's pulled down dynamically
<geist>
and obviously you can just eschew using web pages, etc etc but i'm not willing to go that far
<gorgonical>
indeed. I remember about ten years ago it felt like Linux was actually, substantially getting better. Nowadays I just use slackware because I know new stuff won't appear "just because"
<gorgonical>
Obviously drivers and good stuff still make it into distros, but I happily use claws as my mail app and I think this release must be like five years old
<bslsk05>
www.amazon.com: Amazon.com: USB to TTL Serial 3.3V UART Converter Cable with FTDI Chip Terminated by 6 Way Header, Works with Galileo Gen2 Boards/BeagleBone Black/Minnowboard Max and More : Electronics
<bslsk05>
pinout.xyz: Raspberry Pi GPIO Pinout
mahmutov has quit [Ping timeout: 256 seconds]
<radens>
whoops I meant to send that to the raspberry pi channel, sorry
<radens>
(but if someone has an answer I'll take it anyway :P)
sortie has joined #osdev
sortie has quit [Quit: Leaving]
<Affliction>
could probably bodge an "adaptor" together with a couple of wires and a similar connector
<Affliction>
You'd want to connect GND to GND (naturally), TX to RX, and RX to TX, RTS/CTS are used for hardware handshaking, which the pi doesn't have. They MIGHT be able to be left open circuit?
<Affliction>
Or they could be tied to 3v3 or GND as appropriate
<klange>
radens: the answer is you get four new dupont terminator terminated cables and plug them into the right bits
<klange>
ignore cts and rts; vcc, ground, tx, rx are in that order at pins 4,6,8,10
<Affliction>
should VCC be connected?
<Affliction>
sure, if that powers the other side of an isolation barrier in the adaptor, but, is that the case with that cable?
<klange>
Hm, my rs232 adapter needs the voltage reference, but RS232 is ... weird voltage.
<Affliction>
if that's a reference for the data lines, it should probably go to 3.3, not 5
<Affliction>
At least, I've killed the original pi with 5V, maybe the newer ones can tolerate it
eschaton has joined #osdev
Brnocrist has quit [Ping timeout: 240 seconds]
<Affliction>
Something to confirm, if it's sourcing power, you really don't want it connected to anything. If it's a reference, 3.3
<klange>
why couldn't they just do rs232 and save us all this mess
<Affliction>
cost, I guess
<Affliction>
The original design was supposed to be a $25/$35 computer
Brnocrist has joined #osdev
<Affliction>
level shifters and connectors cost money
ElectronApps has quit [Remote host closed the connection]
givemeyourpies has joined #osdev
<klys_>
yeah there are so many reasons to usb connector, as I have found at work
ElectronApps has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
m3a has quit [Quit: leaving]
GreaseMonkey has quit [Remote host closed the connection]
[itchyjunk] has quit [Remote host closed the connection]
ping- has quit [Ping timeout: 268 seconds]
mctpyt has joined #osdev
<radens>
@klange thanks, I'll look into it
<radens>
I kind of thought that was the answer (or, buy a new cable), but I was secretly hoping that I could just jam the thing into the gpio header and it would work
xenos1984 has quit [Quit: Leaving.]
Ikkepop has quit [Ping timeout: 250 seconds]
<Affliction>
Yeah, that'd probably end poorly
jafarlihi has joined #osdev
<jafarlihi>
Hello. I'm kinda new to x86 assembly and can't use Intel manuals as a quick reference. I found project called x86-manpages in GH but wanted to ask if you guys/gals know of any better way?
<jafarlihi>
Googling is kinda moot when it comes to asm
<zid>
what's your problem with the manual?
<jafarlihi>
For instructions I need the 2nd manual, right? Well, for example I want to be able to search "div" and get relevant info right away -- it is rather hard with the manual
<zid>
I guess, but scrolling the left bar is fine by me
<jafarlihi>
I just want to keep my hands on keyboard
<jafarlihi>
I'll check that, thanks
<zid>
It's just the manual copy pasted to individual pages
<zid>
(I can't imagine needing to look up enough instructions to give a flying fuck how hard it is to look one up, btw)
<moon-child>
jafarlihi: x86-manpages probably is fine. But yeah, what zid said
richbridger has joined #osdev
<geist>
hmm, finally going back and wiring up io apics and whatnot
<geist>
what i haven't figured out without MSIs, how does one assign PCI devices to 'high' global sys interrupts?
<geist>
so for example, i have a qmeu here with like 4 ahci controllers, all mapped to 10
<geist>
but surely there's a way to assign them individually to higher GSI vectors, but the MADT table doesn't give me any such info
<geist>
obviously MSIs mostly supercede this of course
<geist>
some references on the interweb to the $PIR table
<geist>
ah and then mptable and then via a bunch of methods on devices on the ACPI tables. boo
ElectronApps has quit [Read error: Connection reset by peer]
GeDaMo has joined #osdev
jafarlihi has quit [Quit: WeeChat 3.3]
givemeyourpies has quit [Quit: Going offline, see ya! (www.adiirc.com)]
ElectronApps has joined #osdev
xenos1984 has joined #osdev
gog has quit [Quit: byee]
gog has joined #osdev
vdamewood has joined #osdev
<geist>
oh ugh, reading about _PRT and whatnot. this sucks. can't really sanely support this without a full acpi bytecode interpreter
<zid>
Sounds like it doesn't actually have that feature then
<kazinsal>
yeah if you can support MSIs it's saner to use those instead of trying to IOAPIC it seems
mctpyt has quit [Ping timeout: 260 seconds]
<geist>
yah what's slightly unclear is what happens if you try to use MSIs without properly configuring ioapics and whatnot
<geist>
can you simply leave everything in virtual wire PIC mode and then just tell devices to use MSIs and please dont fire IRQs on regular interrupts? (probably)
<kazinsal>
well, PCIe doesn't have INT# lines and it uses the MSI mechanism to emulate them
<kazinsal>
which the IOAPIC passes through in virtual PIC mode
<geist>
sure but generally you disable virtual pic mode (and there's even a ACPI method your'e suposed to call)
<kazinsal>
yeah
<geist>
but if you just configure a device to use MSI i guess as long as it doesn't try to fire a legacy IRQ all is good
<kazinsal>
MSI configuration is mostly done on the LAPICs I think
<geist>
also alternatively you can use the mptable, which predates ACPI but probably is still there
<geist>
and it also describes how busses wire things to ioapics
<kazinsal>
just reading the MSI whitepaper from intel to check
<geist>
haven't found a utility on linux to dump the mptable, but freebsd has a utility for it
<kazinsal>
yeah, looks like no IOAPIC needed for MSI
<kazinsal>
"The MSI model eliminates the devices’ need to use the IO-APIC, allowing every device to write directly to the CPU’s Local-APIC."
<kazinsal>
so you can service non-MSI devices through the virtual PIC and MSI devices through MSI
<geist>
and i guess it's device specific mechanism to configure it to use MSI and explicitly not fire IRQ
<kazinsal>
yeah
<geist>
probably this is what i'll do. you either get PIC or MSI but none of the ioapic stuff
<geist>
or at least can use ioapic, but just leave it in virtual wire mode
<gog>
woo found why my semicolon key was jammed up
<gog>
tiny flake of stone stuck under it
<gog>
now i can resume code
<j`ey>
gog: were you just chaining expressions with , ? :P
<gog>
j`ey: no i was just pressing the key really hard instead of fixing the problem :p
<j`ey>
hah
<zid>
It would have been a fleck of tree, but iceland, so it had to be stone
<kazinsal>
MSI enable is bit 16 of the first dword of the MSI capability register in the PCI config space for a device
<geist>
word
<gog>
tbf tho i'm always hesitant to remove chiclet-style keys because i've broken the little plastic riser thingies too often
<kazinsal>
MSI-X requires a lot more per device config
<zid>
oh yea, nasty
<zid>
similarly, I need to fix my monitor, but I don't dare dismantle it because I am afraid of shitty plastic clips and glue
<geist>
kazinsal: yah. also never got it completely straight if it's okay to imeplement a device that is MSI-X only, or does it always have to fall back to MSI, or some combination thereof
<kazinsal>
yeah, same
<geist>
iirc qemu has some devices that do MSI-X or gtfo, and i thought i remember someone saying that's not technically legal, etc
archenoth has quit [Read error: Connection reset by peer]
elastic_dog has quit [Ping timeout: 250 seconds]
elastic_dog has joined #osdev
givemeyourpies has joined #osdev
<klange>
since i have this faulty ethernet jack, i added notifications (and correct checking of the UP status bit) to the network status widget so I can see when I've gotten it reconnected
<klange>
Question for the channel: The orientation of the jack is "correct" - should I make it wrong because it looks more normal upside down?
<Mutabah>
I usually think of it as clip at the top
<klange>
Much like the ground pin on a NEMA socket, it's "supposed" to be down.
<klange>
Er
<klange>
Much like how the ground pin on a NEMA socket is supposed to be up...
<klange>
the clip is supposed to be down
<klange>
"The opposite of what everyone actually does in practice"
<klange>
To be fair, like, on laptops you want the clip on the top so you can get your finger into it...
<klange>
I think it's supposed to be that the pins are on top so that debris doesn't get stuck on them - like if you leave a port empty it'll collect dust...
<zid>
I like the icon other than the pins being very long looking
archenoth has joined #osdev
sikkiladho has joined #osdev
nyah has joined #osdev
<sikkiladho>
In armv8-a, there are modes and exception levels. User mode is where user applications run, but same is true for Exception Levels. What's the difference?
<sikkiladho>
There can different modes in the same exception level?
<sikkiladho>
SVC, ABT, IRQ, FIQ, UND,SYS have the same exception level. What is the point of it?
<bslsk05>
'Which Way Is Down?' by Vsauce (00:26:10)
<heat>
close
<sham1>
Which way is down is such a good video to explain this stuff even though it goes a bit hand-wavy
<gog>
the nearest gravity well or the one you're falling into? might not always be the same :D
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<GeDaMo>
Up is a quark :|
<sham1>
Well so is down
<sham1>
And beauty
<gog>
and top/bottom
* vdamewood
reverses GeDaMo chirality.
<GeDaMo>
And strange and charm
<gog>
GeDaMo: you lepton that pun
<gog>
:D
<sham1>
Of course everything consists of strings, so be sure to include that .rodata
<vdamewood>
gog: I would say the 'most influential', but that would probably be the nearest one since gravity goes doen exponentially in relation to distance.
<bslsk05>
'Hawkwind..Quark Strangeness And Charm' by Serdar Koz (00:03:45)
<sham1>
Now that is a punny title
<gog>
i'm 4 out of 6 quarks bet you can't guess which
<heat>
top bottom strange and charm?
<gog>
damn am i that predictable
<vdamewood>
Why are there no switch quarks?
chibill[m] has joined #osdev
<gog>
vers quark
<heat>
quark grindr?
<heat>
fissionr?
Cyro has quit [Ping timeout: 260 seconds]
zaquest has quit [Quit: Leaving]
<chibill[m]>
Question is there a good way to test interrupts from C? I tried a divide by 0 but either my compiler is being to smart for its own good or interrupts aren't happening at all.
<sham1>
If you're not afraid of using a little bit of inline assembly, on x86 you could do `asm volatile("div $0");`
<heat>
the compiler identifies certain things you're doing to trigger exceptions as UB
<heat>
which they totally are btw
<heat>
things like char *ptr = NULL; *ptr = 'A'; will just give you a ud2 and illegal instruction exception
CaCode- has quit [Remote host closed the connection]
<chibill[m]>
Hm That doesn't trigger my handler nor does it cause a triple fault or anything to happen. :/ Is Qemu doing something weird to me.
CaCode- has joined #osdev
<chibill[m]>
nvm
CaCode- has quit [Remote host closed the connection]
isaacwoods has joined #osdev
CaCode- has joined #osdev
CaCode- is now known as CaCode
pretty_dumm_guy has joined #osdev
pretty_dumm_guy has quit [Client Quit]
<chibill[m]>
So its definetly loaded and valid enough not to triple fault but my handler doesn't seem to be getting ran.
pretty_dumm_guy has joined #osdev
gdown has joined #osdev
<heat>
qemu -d int
mctpyt has quit [Ping timeout: 268 seconds]
FreeFull has joined #osdev
XgF has quit [Remote host closed the connection]
mctpyt has joined #osdev
XgF has joined #osdev
* geist
yawns
<geist>
good morning folks
<heat>
you mean afternoon?
* heat
laughs in GMT+1
<GeDaMo>
It's evening! :P
tacco has joined #osdev
<chibill[m]>
I think I need to just start over on setting up the IDT. Think I am doing something wrong in some way.
mctpyt has quit [Ping timeout: 245 seconds]
<geist>
it's tricky to get right the first time
<geist>
the cpu is not forgiving with things like the IDT and GDT. it just be precisely correct
<chibill[m]>
I think my GDT is correct as after implementing it my kernel still works.
<chibill[m]>
As much as it does.
<chibill[m]>
Now the IDT I have no idea yet.
<j`ey>
chibill[m]: if youre using qemu, '-d int' as heat suggested is useful
<chibill[m]>
I looked at that but I can't seem to figure out what I am looking at.
<j`ey>
it should show you if oure oure getting interrupts
<heat>
it's an interrupt log of the vm
<heat>
with register state and everything
<geist>
we might be able to help if you pastebin one of the reports
<geist>
i'm gonna guess its showing an int that immediately gets elevated to double and triple fault because something isn't right on your idt
<geist>
in qemu you can also use `info registers` to see if your `lidt` is working properly
<geist>
it'll show the base and length field you loaded into it
<heat>
I have some questions regarding block devices: Does AHCI define the order in which command lists are executed? And do SSDs have a read head kind of thing or is disk locality not really a thing?
<geist>
good question. my guess is no and no, but i can't tell you definitively, since i haven't written an AHCI driver
<gog>
afaik disk locality is meaningless for SSDs because of wear leveling
<geist>
NVMe though definitely does commands out of order, except where you can insert flushes and barriers
<gog>
if it does wear-leveling on the controller anyhow
<gog>
and AHCI has NCQ on by default for rotating disks also iirc
<chibill[m]>
I would expect a triple fault to cause qemu to reset, it doesn't reset. Here all the output from qemu when running my kernel. https://pastebin.com/re7gC86X
<bslsk05>
pastebin.com: SMM: enterEAX=00000001 EBX=00000000 ECX=02000000 EDX=02000628ESI=0000000b ED - Pastebin.com
<geist>
yah, i forget precisely how NCQ works, but i think it's fairly implicit to the design that it runs things out of order
<geist>
chibill[m]: so which one is the first?
<geist>
actually looks like there's only one at the end
<geist>
see where the v= line is?
<geist>
also see your IDT load, does `IDT= 00103010 000007ff` look correct?
<chibill[m]>
yea
<geist>
so your first and only interrupt appears to be `0: v=08 e=0000 i=0 cpl=0 IP=0008:0010047c pc=0010047c SP=0010:00107814 env->regs[R_EAX]=00000000`
<geist>
that's a double fault, so interesting that it went directly to that
CaCode has quit [Remote host closed the connection]
<geist>
is there anything special about the PC where it faulted?
greaser|q has joined #osdev
<heat>
I'm asking because I'm trying to figure out how an IO scheduler should work but it seems to get more complicated when you abandon IDE mechanical drives and go to AHCI/NVMe
<chibill[m]>
Weird, I used "char *ptr = NULL; *ptr = 'A';" to cause the interrupt to test.
<chibill[m]>
I am guessing something is wrong with my IDT then. Need to write a function to print pointers to see if my IDT is set correctly.
<geist>
heat: i think the general trend is dont bother io scheduling. just let the disk deal with it
<geist>
hence using nop scheduler on linux with SSDs, etc
<heat>
geist, nop also does scheduling, it's not completely nop
<heat>
it orders the requests on locality
<geist>
chibill[m]: yah also compiler may replace that with something else
<geist>
i wouldn't be surprised if the compiler didn't replace your page fault with a ud2
<geist>
so if you dont have all the exceptions filled out it might not be firing what you think
<geist>
if you want to test the idt i'd highly suggest somethin like `asm volatile("int3");` and verify it in the disassembly
<geist>
trying to get the compiler to generate bad sequences is hard
<geist>
or at least subtle
jess has quit [Quit: I try to be an optimist / but my glass is always bone dry]
<chibill[m]>
hm it generates the 03 inttrupt but my handler seems to do nothing.
<chibill[m]>
I am going to re-do all my IDT code to make sure it all makes sense.
<gog>
it might be actually
<gog>
now that i think about it
<gog>
like if the controller knows the mappings for LBA to actual location then it can queue it all up and cache it before doing the writes
<gog>
idk enough about it tho i'm pure speculation
<heat>
I would think it does some sort of readahead too
<gog>
yeah most likely
<gog>
since writes are destructive
<heat>
since realistically most files are super contiguous and it has a bunch of dram
<chibill[m]>
Figured it out. Turns out it helps it you set the address for a table of handlers right. (I was basing my code off both the IDT docs, the Interrupts Tutorial and also XV6)
<chibill[m]>
Hm now I get different behavior depending if I run qemu with -d int or not. Without it it works fine, but with it I start spamming GP faults and Double Faults
X-Scale has quit [Ping timeout: 250 seconds]
X-Scale` has joined #osdev
X-Scale` is now known as X-Scale
GeDaMo has quit [Remote host closed the connection]
dude12312414 has joined #osdev
srjek has joined #osdev
ahalaney has quit [Quit: Leaving]
gog has quit []
gog has joined #osdev
AndroUser2 has quit [Ping timeout: 264 seconds]
<heat>
chibill[m], fyi IMO xv6 isn't a great source
<heat>
you should use something else in all honesty
<heat>
it's like they banned comments from source code
<heat>
and useful commit messages
<sham1>
Not having useful commit messages? Sounds like most companies
<heat>
there are commits named "x" and "die"
<heat>
they also scrapped the original xv6 because they wanted to migrate to riscv and screw portability am I right
<chibill[m]>
Its one that I was familiar with working on, as i had to implement new features into for a CS class a year or two ago.
<chibill[m]>
It has a pdf book that explains alot of how it works. :p
<chibill[m]>
Yea. They aren't maintaining the original. But hey its their teaching OS :p
Ikkepop has quit [Ping timeout: 260 seconds]
<heat>
the fact that xv6's code reminds me of FreeBSD isn't great considering xv6 is for teaching and freebsd is a real OS
Maka_Albarn has joined #osdev
<Maka_Albarn>
Hey, does it matter when you set up the GDT reletive to paging?
<heat>
no
<heat>
but the GDT needs to be a valid pointer
<Maka_Albarn>
thank you. I plan on calling my page table setup from my boot.s, and I wanted to make sure that I didn't need the GDT for that first.
<Maka_Albarn>
I'm planning on identity paging the first few MBs
<heat>
yeah
<heat>
generally you need to do the first bits of paging before the gdt
<heat>
since you'll need to switch to long mode when x86_64
* Maka_Albarn
nods
<Maka_Albarn>
that makes sense
<Maka_Albarn>
gotta go, classes.
Maka_Albarn has left #osdev [#osdev]
unmanbearpig has quit [Ping timeout: 260 seconds]
YuutaW has quit [Ping timeout: 264 seconds]
tacco has quit [Remote host closed the connection]
<geist>
though you need at least a temporary one to get into protected mode, etc
<zid>
I don't need new ones I'm still vulnerable to pop ss
<geist>
also apparently substitute syscall for int3
<klange>
no please stop
<zid>
Why are you fixing a 10+ year old exploit?
<klange>
I don't even want to imagine what terrible things I've opened myself up to by providing a debug interface...
<geist>
i thought this one was newer, like 2018
<geist>
pop ss is older, i think
<geist>
but it all has to do with the one instruction gap where exceptions are disabled after fiddling with ss
<zid>
oh I think maybe it was reported in 2018
<zid>
but my cpu from then is vulnerable and won't be fixed
<geist>
trick here is it fires a #DB because you hit a watchpoint, but then delays delivering it until the cycle *after* it enters kernel space via the syscall
<geist>
so you get a #DB that appears to fire on the first instruction of the syscall handler