<mykernel>
apic irqs not working on amd cpu, but works on everything else (qemu, bochs, 2 very different intel cpus). i already had some problems like that in the past that were solved by setting some bit in some msr (usually defined in amd manual). but now i cannot find the culprit
<heat>
define apic irqs
<heat>
which IRQ?
<mykernel>
timer & keyboard
<mykernel>
ioapic redirected
<heat>
LAPIC timer?
<mykernel>
PIT
<heat>
did you look at the ACPI tables?
<heat>
PIT probably has a redirection to 2
<mykernel>
yeah i did remaped 2 to 0 (gsi)
<heat>
try the LAPIC timer
<mykernel>
only exceptions are triggered, no other irq is even triggered
<mykernel>
on amd cpu
<heat>
1) it's better 2) may help rule out the IOAPIC
<mykernel>
will do it next ty
<heat>
it's hard to guess off the top of my head what's actually wrong
<heat>
did you redirect the IRQs to the current CPU? did you unmask them?
<mykernel>
i am not yet dealing with pci and parsing aml
<heat>
this has nothing to do with PCI
<heat>
you SHOULD call this
<heat>
an easy way to see if that's the problem would be to dump this method from linux and see if it does anything magical
<heat>
i'll also imagine your MMIO caching is all properly configured, without relying on the MTRRs
<heat>
and that you're not doing something like erroneously assuming x2APIC on an older AMD that does not have it
<mykernel>
btw just tried ap init on this amd cpu and it triple faults
[itchyjunk] has joined #osdev
<geist>
oh woot, got my visionfive 2 board
zaquest has joined #osdev
<heat>
woooooooooooooooooooooooooooooooooooot
<heat>
geist, does it have fairly standard hardware?
<heat>
the uart, etc
<geist>
dunno. haven't deep dove in it yet. last i checked the JH7110 soc didn't have any docs yet
<geist>
but it's close to a 7100 and that has google translated docs from chinese
<geist>
and there's some branch for linux, so there's your docs
<geist>
probably a 16550, yeah
<heat>
yay linux-as-documentation
<geist>
the cores are sifive u74s which are pretty stanrad. outside of that i hvae no idea. has dual gigabit, pci, hdmi, etc. no idea how standard those are
<heat>
i still don't quite understand if using GPL code as docs is a GPL violation
<heat>
I would guess "no" but IANAL
<heat>
if so, I would guess most people would be very screwed
<heat>
e.g I've seen some suspiciously similar code between linux ext4 and freebsd ext4
<netbsduser`>
microsoft plucked alex ionescu from the reactos project (gpl) to work on Windows, which speaks volumes
<kazinsal>
his documentation is really good
<netbsduser`>
the "no reading gpl" policy some projects have is probably just an overcorrection to make it impossible to argue that the code was derived from GPL stuff
<geist>
i think that's exactly right
<geist>
you can after the fact legitimately argue that you were following the project rules, etc
<geist>
even if you broke them
<mykernel>
heat: fixed it - bad curr_cpu_apic_id() function which always returned 0x0 (worked for intel cpus lol)
<heat>
hah
<heat>
i guess in AMD the BSP is not guaranteed to be 0?
<heat>
cc geist I guess
<geist>
that's odd. i thought it was pretty much always 0
<geist>
not guaranteed to be consequetive though
<heat>
yeah I was imagining they always stuck with 0 for compatibility purposes
<heat>
mykernel, what cpu is this?
<mykernel>
this amd cpu is really odd (it has 2 normal cores and 2 disabled cores) apic_ids: 0x10 0x11 and 0x16 0x17
<mykernel>
lemme look up
<geist>
yah what you definiteky can't do is use it as a 0 based index into some table, because they're not consequetive.
<geist>
huh. okay. thats i guess possible
<heat>
that's something I did take into account when writing the riscv smp code
<geist>
guess the disabled ones are 0 bsaed. but even that is strange. are you positive you're reading those right?
<heat>
they very frequently use != 0 as the BSP in OpenSBI
<mykernel>
AMD A4 A4-4020
<geist>
say bit 4 is extraneous: then 0,1,x,x,x,6,7 makes sense
<geist>
(one more x)
<geist>
a4-4020 is a fam 15h (richland, using piledriver cores)
<mykernel>
yeah i am certain that those apic_ids are right (when i hardcode 0x10 for bspid everything works)
<geist>
well anyway, could look in BKDG for 15h, but cant be bothered
<geist>
i think the BKDG will describe how the APIC ids are supposed to be allocated
<bslsk05>
gcc.gnu.org: Jeffrey Walton - Proper use of x86/x86_64 CPUID instruction with extended assembler
<heat>
geist, is this a "run off and check if all my projects deal with non-0 APIC ids" moment? :P
<mykernel>
thanks everyone
<mrvn>
mykernel: I would change that function a bit to return a struct CPUIDinfo but that's imho the best way to write inline asm, only do the minimum in asm.
<heat>
because my OS totally does NOT deal with this edgecase
<heat>
i need to take a look at that later
<heat>
.. wonder if there's a way to set APIC ids in qemu
<Mutabah>
My approach is to assume that the APIC IDs could be completely random
<Mutabah>
so convert them to an internal zero-indexed CPU index asap
<heat>
yeah, that's what I did for riscv
<Mutabah>
(and then use `str` to get the TSS selector and use that to determine the current CPU)
<heat>
but * Copyright (c) 2016 - 2022 in my apic.cpp :)
<heat>
I should totally abstract irq controllers and have generic interfaces to route IRQs, etc
<Mutabah>
Ooh, flash of memory, my old kernel used the debug registers to store the current thread and CPU info
[itchyjunk] has quit [Remote host closed the connection]
<heat>
haha
<heat>
can't ring3 touch that?
<Mutabah>
Hey, it worked
<Mutabah>
Pretty sure it can't
<Mutabah>
or at least, can't change it
<heat>
"The debug registers are privileged resources; the MOV instructions that access them can only be executed at privilege level zero."
<heat>
yep
<heat>
that's a very clever trick
<heat>
... one that has been unneeded since $ever but cool nonetheless :D
<Mutabah>
Well, it's simpler than doing TSS/GS tricks
<Mutabah>
but likely much less performant
<Mutabah>
I do love that riscv has a bunch of scratch registers you can use for storing this stuff
<heat>
it has just one
<heat>
the standard is simply to use it to store the percpu base and then swap it with tp
<Mutabah>
*nod*
<heat>
geist, mind testing out the CSR access performance when you can?
<heat>
per amd itself: The APIC ID is located in the APIC ID register at APIC offset 20h. See Figure 16-3. It is model
<heat>
dependent, whether software can modify the APIC ID Register. The initial value of the APIC ID (after
<heat>
a reset) is the value returned in CPUID function 0000_0001h_EBX[31:24].
<zid`>
disregard amd, watch The Whale staring Brendan Fraser
<heat>
"A given implementation may use some bits to represent the CPU core and other bits represent the processor." I assume that natively the CPU starts at 0 up to N and then firmware configures it like the BKDG recommends
<mykernel>
tysm
<zid`>
That's sort for thank you, sadomasochist
<zid`>
short*
<zid`>
heat: When are we picking me out a new computer?
<zid`>
qemu's emulation of writing to memory being
<bslsk05>
github.com: qemu/nvdimm.txt at master · qemu/qemu · GitHub
<zid`>
"writing to memory"
<geist>
in pretty much every case there's no real assumption that it's attempting to be cycle accurate or whatnot
<geist>
with disks, network, etc too
<geist>
nvdimm i suspect memory maps some stuff, so it may be almost impossible to do what you want
<Mutabah>
Why do the latencies matter to you?
<zid`>
He's been talking about them for years
gxt_ has joined #osdev
<zid`>
I haven't figured out a pattern to why yet
<vin>
Mutabah: I am simulating CXL memory devices.
gxt has quit [Remote host closed the connection]
<vin>
As memory gets more hetrogeneous (DRAM, CXL, NVM, RDMA based far memory) they all exhibit different latencies
<geist>
also keep in mind nothing else about what qemu is doing is timing accurate, so even if you wrote a driver that did this, its still in a sea of non timing accurate devices
<Mutabah>
And you'd like to profile the performance impact?
<geist>
any sort of timing you derive there would likely be seriously skewed
<vin>
I want the ability to set latency and bandiwdth of a virtual device arbitrarily so I can build applications on top of them that matches real performance
<vin>
So I can either simulate (collect all the instruction trace + memory references) and add latencies manually) or emulate (use NUMA memory, Optane, or "a virtual device") the application slowdown on these slower memories
<vin>
The problem with NUMA memory/Optane DIMMs is that they provide a fixed range of latencies, but I want to be able to set arbitrary load/store latency for a memory device
<Mutabah>
I agree with geist - qemu's other timing quirks will make timing taht very difficult.
<Mutabah>
However, you could probably profile/determine what your memory access patterns are - and then just multiply that by the known device lantencies
<Mutabah>
BUT...
<Mutabah>
on a real CPU, there are caches and out-of-order cores that will change the effective timings
<vin>
Exactly why I would want to emulate rather than simulate
<vin>
But for emulation, I am not able to find a good solution
vdamewood has joined #osdev
<vin>
geist: Do you know any way to achieve this?
<geist>
no
<zid`>
a million dollar simulator box
<zid`>
or math
<vin>
lol, so we all wait for these devices to arrive and only then design apps to accommodate them!?
<geist>
well intel cancelled optane
<geist>
so i guess that's not a thing
<geist>
look i'm not sayign there isn't a way to do whast you want, i just dont know of how
<geist>
but it seems like an extraordinary amount of work
<vin>
Optane might have gone away but almost all major companies are trying out CXL
<vin>
hmm
<zid`>
geist: Can you fix my youtube at least?
* geist
waves hand
<zid`>
seems to work with no cookies at least
<vin>
Maybe I should just rely on a FPGA based device emulators, would likely be the easiest path to take
GeDaMo has joined #osdev
air has quit [Ping timeout: 260 seconds]
<zid`>
GeDaMo: 190/206 +103, stuck now
<GeDaMo>
I clear cookies so I don't have all the words any more :P
<bslsk05>
github.com: lk/platform.c at a319a1f68d592529c03a1e95c369ffc0a2ed20cd · littlekernel/lk · GitHub
<dinkelhacker>
Seems like you're only reading the memory node from the dtb?
craigo has joined #osdev
fedorafan has quit [Ping timeout: 252 seconds]
danilogondolfo has quit [Remote host closed the connection]
<clever>
dinkelhacker: part of it, is that LK is built for a specific arm core, and wont work on any other model, and if you know what model your targeting, you already know the mmio base
<clever>
dinkelhacker: part of it is probably to enable it to work without dtb, and to enable serial while parsing the dtb
danilogondolfo has joined #osdev
<clever>
but that also assumes, the mmio hasnt been moved, the hardware is fully capable of doing that
<clever>
ive booted a pi3 with the mmio base at 0x2000_0000, just to see if it was related to a bug i had
danilogondolfo has quit [Read error: Connection reset by peer]
bl4ckb0ne has quit [Remote host closed the connection]
bl4ckb0ne has joined #osdev
fedorafan has joined #osdev
mavhq has joined #osdev
<zid`>
GeDaMo: <10 mins achi is a thing apparently
<GeDaMo>
Yeah, it seemed pretty easy today
<dinkelhacker>
clever: why is it built for a specifc core? To keep the image size as small as possible?
<dinkelhacker>
Otherwise with more dtb usage one could support many boards with the same image.
<dinkelhacker>
Another question I have is regarding its `apps` are they run by default at the same privilige level as the kernel itself. I see there is a function `arch_enter_uspace' but it seems like it is only defined and never used.
danilogondolfo has joined #osdev
smach has joined #osdev
craigo has quit [Quit: Leaving]
<dzwdz>
hi
<dzwdz>
if i have an os-specific toolchain, is it built seperately from the generic one, or can i reuse work?
<dzwdz>
because if i understand correctly i'll still need the generic freestanding toolchain for building the kernel
<dzwdz>
i'm trying to understand why one would go through the trouble of setting up yet another toolchain
<dinkelhacker>
you'll need a cross compiler built for your os to compile for your target
<dzwdz>
i mean, do i? my cc is currently just a small shell script that launches the freestanding compiler with the right flags
<dinkelhacker>
I'm not sure if I understand the question correctly. What is "the freestanding compiler" and what is "the generic one"?
<dzwdz>
by both i meant x86_64-elf
<dzwdz>
it's what i'm currently using both to build my kernel and userland
<dzwdz>
i am at the point where i think i need to set up an os-specific toolchain, since i want to port binutils and gcc, but i'm trying to figure out why would i want to use it when building on the host
<dinkelhacker>
okay so I think I misunderstood you.
<dinkelhacker>
So basically you're asking yourself if you need a compiler "that knows about" YOUR kernel/os?
<dinkelhacker>
Or if you just could also use the one that you built your kernel with.
<dzwdz>
basically
<dzwdz>
the question is more "why would i need it", but that's just semantics
[itchyjunk] has joined #osdev
<dzwdz>
for one, autoconf doesn't seem to like my current setup
<dinkelhacker>
Tbh. i've been unsure about that aswell. I'm far from that point so maybe some of the more experienced guys must help.
<dzwdz>
it wouldn't be too bad if i could build the two toolchains together
<dzwdz>
but i don't think that's the case
elastic_dog has quit [Remote host closed the connection]
<bslsk05>
wiki.osdev.org: OS Specific Toolchain - OSDev Wiki
Piraty is now known as ytarip
<dzwdz>
not really
<dzwdz>
unless you mean with setting up the custom toolchain
<dzwdz>
then yes
<dzwdz>
i just still don't get why
<dzwdz>
and i'm still confused about the build process
<dzwdz>
OH, the custom toolchain will still be able to build the kernel, it still supports freestanding builds
<dinkelhacker>
Yeah, I also don't get why it might be super usefull... the articels I found on osedv.org just say that it saves you all the compiler flags to os specific stuff. I mean that is probably nice because otherwise you'll have to edit all the makefiles of the programs you want to port so it will use your libc etc.
<dinkelhacker>
Thinking about it.. that kind of makes it ;super usefull'
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
bauen1 has joined #osdev
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 246 seconds]
zaquest has quit [Quit: Leaving]
alexander has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
alexander has joined #osdev
joe9 has joined #osdev
fedorafan has quit [Ping timeout: 252 seconds]
<mrvn>
dzwdz: it's hard to build any apps without a libc and stuff
<sham1>
You either have a libc or a library that can do everything the libc can but different
<dzwdz>
what's the difference
<mrvn>
between a libc and no libc?
fedorafan has joined #osdev
<dzwdz>
between a libc and a library that does everything a libc does
<dzwdz>
currently i was just manually doing -lc
<mrvn>
one is a libc and the other is different
<dzwdz>
ah cool
<sham1>
One follows the C standard and all that comes with it, while the other doesn't. Consider the Windows API for example
<mrvn>
-lc is far from the only thing you use for apps
<dzwdz>
ik
<sham1>
It's got files. Directories. Heap allocation. IO. Some maths as well IIRC, and a lot more
joe9 has quit [Quit: leaving]
mykernel has quit [Quit: leaving]
Matt|home has quit [Remote host closed the connection]
Matt|home has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
frkazoid333 has quit [Read error: Connection reset by peer]
frkazoid333 has joined #osdev
xenos1984 has quit [Quit: Leaving.]
SpikeHeron has quit [Quit: WeeChat 3.8]
SpikeHeron has joined #osdev
<dzwdz>
> error: Please use exactly Autoconf 2.69 instead of 2.71.
<dzwdz>
do y'all think anything bad will happen if i just comment that check out
<gog>
autoconf 2.70 made changes that might break some scripts
<gog>
so you can try it
<gog>
but it's not guaranteed to configure or build correctly
<dzwdz>
yeah, it doesn't work
<dzwdz>
well, it outputs the configure file just fine
<dzwdz>
but the configure doesn't recognize my os
<dzwdz>
this must be fun for package maintainers
<gog>
autotools is bad times
<gog>
i stay well away
<gog>
if i can avoid it
<dzwdz>
i really wish i could
<dzwdz>
but i'm building binutils and gcc
craigo has joined #osdev
vdamewood has joined #osdev
xenos1984 has joined #osdev
<netbsduser`>
dzwdz: when i am on a linux box i have little choice but to, it usually works out fine
Matt|home has quit [Remote host closed the connection]
Matt|home has joined #osdev
gog has quit [Quit: Konversation terminated!]
fedorafan has quit [Ping timeout: 252 seconds]
fedorafan has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
zxrom has quit [Read error: Connection reset by peer]
<bslsk05>
github.com: lk/platform.c at a319a1f68d592529c03a1e95c369ffc0a2ed20cd · littlekernel/lk · GitHub
<heat>
ok so basically the gist AIUI is so 1) you don't need your platform to have a device tree 2) lk can serve as a bootloader that itself loads the device tree from e.g an sd card
<heat>
and lk is actually commonly used as a bootloader itself for android, etc
<heat>
i think geist has said that he would like some possibly generic platform support with using the dtb, etc
<clever>
dinkelhacker: large chunks of LK are assuming registers like ACTLR do specific things, and lack runtime conditional blocks to react properly, its all #ifdef'd
gog has joined #osdev
<heat>
gog
<gog>
peter falcon
<heat>
ada christian
<gog>
hi
<heat>
hello
<gog>
how are you today
<heat>
fine
<heat>
hbu
<gog>
i'm ok
wootehfoot has joined #osdev
xenos1984 has quit [Ping timeout: 246 seconds]
<heat>
thats good
<heat>
ok is ok
<gog>
low key sad
bgs has joined #osdev
<heat>
naw ok is ok, not sad
<heat>
if ok is sad then ur standards are all wrong
<gog>
i'm both tho
<gog>
i'm ok but i can be sad and ok
<heat>
well if u feel ok then ur at worst slightly sad
<heat>
and being slightly sad is ok
CryptoDavid has joined #osdev
xenos1984 has joined #osdev
bnchs has joined #osdev
<heat>
gog gog gog gog
<heat>
how do you write a good cover letter
<heat>
teach me senpai
terminalpusher has joined #osdev
awita has joined #osdev
<gog>
idk actually
<gog>
just a couple paragraphs introducing yourself, your knolwedge, education and prior work
<gog>
and then another about how you can apply that to the job advertisted
<gog>
and then finish up with what you find interesting about the company and its product
<heat>
ok done
<heat>
thank
<gog>
cover letters are mostly to weed out people who are just spamming applications and don't have a particular interest in the job
<heat>
i think it's not great but oh well
<gog>
it doesn't have to be special
<heat>
I find it really awkward to praise myself this much
<heat>
it's like looking at myself in the mirror and jacking off
<gog>
doesn't have to be praise, you can talk about things you don't know enough about and need to learn
<heat>
no im obv perfect
<heat>
u know, now that i think about it, i truly am the greatest
<heat>
praise me
<heat>
i demand worship in exchange for making your crops fertile and fruitful
* sakasama
feeds heat a bag of potatoes.
frkazoid333 has quit [Read error: Connection reset by peer]
frkazoid333 has joined #osdev
ilovethinking has joined #osdev
<ilovethinking>
hey gals
<ilovethinking>
what's up
<heat>
did u just call me a gal
<lav>
hi im a gal
<nikolar>
Rude
<ilovethinking>
heat nikolar sorry :(
<nikolar>
Lol im kidding
<ilovethinking>
getting grub-mkrescue to work on macos is so fucking hard
<ilovethinking>
ffs
<heat>
lav: hi gal, im heat
<heat>
i provide warmth
<heat>
and high quality operating system code
<heat>
whatever you prefer
* lav
holds her toes near heat
<lav>
comld
* ilovethinking
walks away
<lav>
:3
<heat>
colon three moment
<gog>
COLON THREEEEE :3 :3 :3 :3
<lav>
0x3a33
<dzwdz>
woo i finally managed to build binutils
<gog>
:o
<dzwdz>
i almost didn't have to patch any nested makefiles
<dzwdz>
almost
<bnchs>
:3
<bnchs>
hiiii
<ilovethinking>
heat: you are a colon three
<nikolar>
Ɛ:
<dzwdz>
E:
<lav>
cat!
<bnchs>
hi lav
<heat>
dzwdz, I was writing a "How to port toolchains to your OS" guide but forgot about finishing it
<lav>
hi bnchs
<bnchs>
heat: i need that guide for something
<dzwdz>
step 1. accept defeat
<heat>
i don't feel particularly confident writing it because I know enough to understand more or less how things work but little enough to possibly be misguiding someone
<bnchs>
but you know more than me
<dzwdz>
i think you should go for it anyways
<bnchs>
therefore i am more confident on you
<dzwdz>
just note that you might be wrong at the start
<dzwdz>
as in add a note
<gog>
hi bnchs
<gog>
hi lav
<bnchs>
hi gog
<lav>
hi gog
<bnchs>
how are you
<nikolar>
Hi gog
<gog>
hi nikolar
<gog>
i'm ok thanks
<dzwdz>
good old games
<dzwdz>
i bet that's an original joke
<gog>
very
<dzwdz>
:D
<gog>
:D
<dzwdz>
D:
<gog>
D:
<dzwdz>
::
<nikolar>
:)
<heat>
D:D:D:D:D:D:D:D:D:DD:::D:D:D:D::D:D:D:D:
<ilovethinking>
ld: symbol(s) not found for architecture arm64
<ilovethinking>
do i change the arch to x86_64 elf blablabla
<gog>
leg64
<ilovethinking>
-m elf_x86_64
<ilovethinking>
ok tu
<ilovethinking>
ty
<dzwdz>
⍨
<ilovethinking>
make LD="ld.lld -m elf_x86_64"
<ilovethinking>
hmm still same error
<bnchs>
i need to write a toolchain for an OS i'm rewriting to a layer, ughhh dumb work
<heat>
what are you doing
<ilovethinking>
heat: i am trying to compile grub2 cli tools on ma
<ilovethinking>
c
<geist>
heat: that's right
<heat>
i think there's a brew for grub2
<geist>
most platforms/arches of LK are not 'generic' in that they dont attempt to dynamically configure the drivers, etc
<geist>
PC is somewhat the exeption, since it's mostlyk a dynamic platform
<ilovethinking>
nope, it doesn't exist
<bnchs>
it would have been great if i had an SDK
<bnchs>
had the SDK*
<heat>
geist might know more since he also has a mac
<geist>
what
<gog>
who?
<ilovethinking>
pitust: are you present? ik you own a mac
<lav>
why?
<heat>
geist, re ilovethinking's grub2-mkrescue needs on macOS
<geist>
ah. no idea
mctpyt has joined #osdev
<geist>
almst certainly the host toolchain is insufficient though
<geist>
though i dunno, maybe it has ELF or whatnot support?
<heat>
i bet there's a solid chance it doesn't compile with normal linux clang either
<geist>
i always build a cross toolchain first anyway
<heat>
all lld's support all binary formats, at least by default
<gog>
replacing more code with less is always a good feeling
<bnchs>
i replaced more code with more code
wootehfoot has quit [Read error: Connection reset by peer]
awita has quit [Quit: Leaving]
ilovethinking has quit [Quit: i probably locked my mac and i got disconnected]
<heat>
dragonfly bsd
fedorafansuper has joined #osdev
fedorafan has quit [Ping timeout: 252 seconds]
* CompanionCube
randomly looks: fx-8350, there's both an 0-7 initial apicid and another apicid that goes 16-23
<gog>
heat: heat
<gog>
heat
<heat>
gog
<gog>
CompanionCube: apicids are not guaranteed to be anything in particular iirc
<CompanionCube>
indeed
<gog>
which is why you have to use the MADT
<heat>
the Intel and AMD manuals actually seem to document the meaning of the APIC id
* gog
look
* heat
smash
<gog>
>:|
<zid`>
samsung got back to me, they gave me enough barcodes to cover a small city
<gog>
i wanna be barcoded
<Amorphia>
zid`: what did you want from samsung
<zid`>
they want my SSD
* Amorphia
pipes gog through a barcode encoder
<zid`>
after they broke it
<geist>
oh nice. yay getting them to RMA it
<geist>
though i guess that's no guarantee they'll replace it right?
<geist>
but really it's not that old, it should still be okay, unless you've somehow beat it to death, and in that case the internal counters should tell the tale
<zid`>
Please take note:
<zid`>
Germany: Do not bring the SSD into a German Post Office.
* sakasama
labels gog as Sure, Not.
<heat>
i guess they will steal it?
<gog>
i like money
<sakasama>
We should hang out.
<gog>
ow my balls
<zid`>
only issue with all this bullshit is
<zid`>
who the *fuck* has access to a printer in 2023
<gog>
a what?
<zid`>
exactly
<zid`>
Even if i had a friend who did, they're now all WFH
<zid`>
I'm having someone *mail* me the shipping label lol
<sham1>
I do, albeit not at home
<sham1>
So you're getting the shipping label shipped
<zid`>
yep
<zid`>
also samsung paying like €30 to import this off me
<zid`>
if they just offered me €30 cash I might accept
<dzwdz>
so i'd generate an intermediary elf, and then use objcopy to create the flat binary out of it?
<gog>
yes
<dzwdz>
alright, thanks
mctpyt has quit [Ping timeout: 252 seconds]
<dzwdz>
i probably should have got that working before changing everything about my toolchain
<gog>
¯\_(ツ)_/¯
<gog>
everything is a learning experience
terminalpusher has quit [Remote host closed the connection]
fedorafansuper has quit [Ping timeout: 248 seconds]
scaleww has joined #osdev
scaleww has quit [Remote host closed the connection]
fedorafan has joined #osdev
<dzwdz>
and in my infinite wisdom i decided this to be the first thing i do after not working on my os for a while
<dzwdz>
so i don't remember the details of how to debug stuff like this
<dzwdz>
i can't figure out how to trace interrupts in qemu
<gog>
-d int
<dzwdz>
yeah that doesn't seem to generate any output
<heat>
disable kvm
<dzwdz>
i'm sleepy and probably fucking up something obvious
<dzwdz>
OH
<dzwdz>
as i was saying
<heat>
tbf it's non-obvious
<dzwdz>
thanks a lot
<heat>
np
cross has joined #osdev
<heat>
i wonder if there could be a way to make it work with KVM
<dzwdz>
i actually vaguely remembered that i should probably disable kvm for something
<dzwdz>
but gdb worked fine
<heat>
yeah gdb works, -d doesn't
<dzwdz>
so i assumed that was it
janemba has quit [Ping timeout: 246 seconds]
<dzwdz>
well, disabling kvm makes the bug disappear
<heat>
haha
<heat>
so what's your actual problem though?
<gog>
that'll happen sometimes
<dzwdz>
i tried compiling my os using a new toolchain
<dzwdz>
it gets into userland and works for a short while until i get a #GP on a movdqa
<heat>
ok
<heat>
so why do you need -d int?
<dzwdz>
because of the #GP
<heat>
that makes no sense
<dzwdz>
i was hoping that it'd maybe give me a hint as to why i get the fault
<heat>
do you have no trap handlers?
<dzwdz>
i do
<heat>
also, spoiler: see movdqa
<dzwdz>
they're kinda garbage for handling stuff that happens in userland
<dzwdz>
yeah, it's an sse instruction
<heat>
yes
<heat>
did you see how it works?
<dzwdz>
by causing a gp?
<heat>
no
<heat>
did you see how it works?
<dzwdz>
it moves aligned values
<dzwdz>
and the address it copies from is 8 byte aligned
<dzwdz>
so i assume that's fine?
<heat>
so you did not see how it works
<dzwdz>
i skimmed the reference
<heat>
ok now actually read it
<heat>
the problem is painfully obvious if you read it
<dzwdz>
oh fucking hell
<heat>
there we go
<dzwdz>
:/
<geist>
heat: enlighten us
<dzwdz>
thanks for guiding my sleepy ass again
<heat>
geist, movdqa like most aligned SSE instructions #GP's on unaligned memory
<dzwdz>
wait no
<geist>
16 byte alignment though?
<heat>
yep
<geist>
dzwdz said it was 8 byte aligned. ah there we go
<dzwdz>
i don't think it's the 16 aligned version
<geist>
worth double checking. almost certainly thats the problem *or* maybe SSE isn't enabled?
<heat>
movdqa is only 16-byte aligned (xmm)
<geist>
so many things go into #GP is really frustrating to figure it out
<heat>
sse being disabled would be a #UD I think
<geist>
probably so yeah
<dzwdz>
SSE should be enabled - it was enabled before, and i doubt changing the toolchain would manage to mess that up
<dzwdz>
oh right
<geist>
well be careu of 'should be' vs 'verified that it is'
<geist>
but yeah it'd be a #UD so that probably takes that off the table
<heat>
so general wisedom from experience would say that you're misaligning the stack according to the System V abi
<geist>
+1
<geist>
doubletrue if you wrote some assembly and forgot to do it yourself
<heat>
other problems could be "malloc borked", etc
* gog
#GP(0)'s
<gog>
good luck debugging me
<dzwdz>
i'm copying data off the stack
<dzwdz>
but the misaligned address is not on the stack, it's hardcoded
<dzwdz>
(don't judge)
<geist>
two easy ways to get the stack misaligned on x86-64: 1) you write asm, forgot to align 2) you started a new thread and at the entry point the stack wasn't intentionaly -8 misaligned
<dzwdz>
i'm not sure where gcc gets the idea that it's aligned
<heat>
what's the address and what's the instruction?
<geist>
is it a global variable?
<dzwdz>
i appreciate that you want to guide me further but i think i'll just go to sleep for now
<heat>
no
<heat>
please
<dzwdz>
lol ok
<dzwdz>
one sec
<heat>
you can't fucking bait me and then nope off
<dzwdz>
also a random struct used by my exec() implementation
<heat>
yes, so what's the struct
<dzwdz>
ed
<geist>
like pastebin the actual struct
k8yun has quit [Quit: Leaving]
<heat>
ok, i'll look into my crystal ball for the source to ed
<dzwdz>
the openbsd ed is a pretty nice one
<dzwdz>
pretty portable
<geist>
poiint is somehow the compiler must be thinking that ed is aligned a paricular way, so it can optimize and use the aligned 16 byte copy instruction
<geist>
so how it's declared precisely and how the variable is defined matters a lot here
<bslsk05>
pastebin.com: i need to go to sleep - Pastebin.com
<dzwdz>
oh i didn't include the declaration
<dzwdz>
execdata is just declared on the stack
<heat>
no, the stack is misaligned
<geist>
ah so possibly back to stack... yeah what heat says
<heat>
movdqa -0xd0(%rbp),%xmm1
<geist>
it knows that ed is aligned a particular way because it can assume the stack is aligned to 16 bytes
<dzwdz>
well, here
<dzwdz>
i done goofed
<heat>
i assume you screwed up the crt0.o/crt1.o and/or the initial ELF load
<geist>
and the ed struct is 16 byte aligned so it's like 'blam i can load this mug into that'
<dzwdz>
it's way more cursed than that
<dzwdz>
but this is related to elf loading
<heat>
how
<geist>
or when you set up the initial stack you didn't declare it as aligned >= 16 and you didn't set the SP properly on the first instruction
<geist>
of the thread, etc
<dzwdz>
it's in a function of the elf loader which needs to run on a separate stack for a tiny amount of time
<dzwdz>
after it's done the new process runs
<dzwdz>
so it's hard for it to corrupt anything badly or whatever
<dzwdz>
because of that
<dzwdz>
i haven't noticed up until now that i'm setting the stack pointer to the address of the page i've allocated for the temporary stack
<dzwdz>
like, to the bottom
<geist>
eep
<geist>
aoso if the start address is a C function, you need to intentionally misaign it
<geist>
there's an assumption at the start of every x86-64 function that the stack is -8 aligned, because there's supposed to have been a call instruction that got it there
<geist>
so if you ever do some sort of direct branch to a new function with a new stack pointer you have to take that into account
<dzwdz>
that's exactly what i was doing here
<dzwdz>
thanks
<geist>
and yeah the bottom vs top of stack thing i've messed up like 40 times
<dzwdz>
i should probably space out page allocations to prevent this
<geist>
yah guard pages are a good idea
<heat>
why is your elf loader running in user space
<heat>
is this a microkernel
<dzwdz>
kinda
<dzwdz>
it's a bad microkernel
<heat>
did I just help out a dirty microkernel fan
<dzwdz>
yes
<heat>
crap
<dzwdz>
you don't even know how dirty this one is
<heat>
do you at least use rust
<geist>
heat: mwahwha
<dzwdz>
bare C
<heat>
ah, a 90s microkernel
<dzwdz>
the network stack is implemented as a filesystem
<heat>
a 90s microkernel that rips ideas from plan9
<dzwdz>
which interacts with the NIC, which is a filesystem
<geist>
heat: the banality of evil, heat. you have helped the cause
<dzwdz>
it's basically what i hoped plan9 was
<dzwdz>
in plan9 you can't switch out the magic #d directory thingies