the compiler keeps crashing when running the testsuite
terrorjack has joined #osdev
i have definitely done nothing wrong
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
troseman has quit [Ping timeout: 240 seconds]
Belxjander has quit [Ping timeout: 272 seconds]
decartes has quit [Quit: Connection closed for inactivity]
[itchyjunk] has quit [Remote host closed the connection]
masoudd has quit [Quit: Leaving]
gog has quit [Ping timeout: 256 seconds]
Jari-- has joined #osdev
mahmutov has joined #osdev
k8yun has joined #osdev
heat has quit [Ping timeout: 256 seconds]
k8yun has quit [Quit: Leaving]
sdfgsdfg has joined #osdev
Grell has joined #osdev
GeDaMo has joined #osdev
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
Grell has quit [Remote host closed the connection]
mahmutov has quit [Ping timeout: 256 seconds]
heat has joined #osdev
hmmmm has joined #osdev
wolfshappen has quit [Ping timeout: 240 seconds]
wolfshappen has joined #osdev
alright, not sure about the rpi's deadlock, but I think I've fixed two rare crashes in hvf; one was that I was neglecting to save/restore fpu status registers, which is kind of amazing that it didn't come up earlier (very rare writes of garbage data to the stack in a couple of fpu-heavy apps)
the other, assuming this fix actually fixed it, was insufficient instruction barriers after switching page directories, which was resulting in very fun data aborts on return from system calls, but examining things after the panic everything looked peachy
i did all of this in the morning and have just been running stress tests in the background while I play pokémon all day
there are so many instructions between "switch to process's directory" and "eret back to el0" I'm still not sure I actually believe that was the source of the problem or the right solution, but the stress tests are reasonably convincing... and these M1's are pretty nuts, I guess I can buy them being a hundred instructions head of the load and triggering the fault only for things to resolve themselves by the
time the exception actually resolves
heat_ has joined #osdev
heat has quit [Ping timeout: 245 seconds]
dayimproper has joined #osdev
ElectronApps has quit [Remote host closed the connection]
Jari-- has quit [Ping timeout: 272 seconds]
ElectronApps has joined #osdev
Burgundy has joined #osdev
pretty_dumm_guy has joined #osdev
I added some deadlock detection but I'd wager it messes with the timing just right to not encounter the bug...
"No fair! You changed the outcome by measuring it!"
That's not good news at all! :P
lkurusa has joined #osdev
yeah concurrency issues suck
lkurusa has quit [Ping timeout: 250 seconds]
Reinhilde is now known as AmyMalik
ran into a bizzare issue with GNU as, maybe someone has seen similar
trying to code up an EFI PE header ala Linux EFISTUB in assembly
I've got a bunch of errands to run today anyway, like handing in my tax paperwork so the 国税庁 can give me back a few thousand yen (read: tens of dollars)
j`ey: what does any of that mean?
that's the description for the register offset store
<Xt> is the data reg, Xn|SP is the memory reg
the rest is unimportant for now
but it says Xt so that means it's the zero reg,
but for Xn it says Xn|SP
so if you had: str x0, [x31].. that would actually be str x0, [sp]
so in instructions where x31 is sp it would say <Xn|SP>?
you'd never(ish) want to have zero as the memory operand, but you do want sp
can you read the stack on aarch64 at all?
what do you mean?
yes, many many instructions let you use sp where an integer register is accepted
important relevant quote from the ARM ARM:
> There is no register called X31 or W31. Many instructions are encoded such that the number 31 represents the zero register, ZR (WZR/XZR). There is also a restricted group of instructions where one or more of the arguments are encoded such that number 31 represents the Stack Pointer (SP).
So to store the SP you have to e.g. x0 = SP + 0; *mem = x0?
why can I not link with crtbeginS.o?
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
error: relocation overflow in R_AARCH64_CALL26
wrong memory model?
i don't think so? I'm using mcmodel=small and linking at -2GB
and the crtbeginS.o is further than 26bit away.
and that's impossible
my kernel is not that big lol
unless the crtbeginS.o is too big or has some section you don't map to -2GB properly