<heat>
the compiler keeps crashing when running the testsuite
<heat>
cheers
terrorjack has joined #osdev
<heat>
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
<klange>
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)
<klange>
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
<klange>
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
<Jari-->
Very interesting!
<klange>
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
<klange>
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
<klange>
I added some deadlock detection but I'd wager it messes with the timing just right to not encounter the bug...
<klange>
"No fair! You changed the outcome by measuring it!"
<GeDaMo>
That's not good news at all! :P
lkurusa has joined #osdev
<moon-child>
hahaha
<moon-child>
yeah concurrency issues suck
lkurusa has quit [Ping timeout: 250 seconds]
Reinhilde is now known as AmyMalik
<ddevault>
ran into a bizzare issue with GNU as, maybe someone has seen similar
<ddevault>
trying to code up an EFI PE header ala Linux EFISTUB in assembly
<ddevault>
I have _edata et al populated in my linker script, but as dies here on line 26 with Error: can't resolve _edata - _data
<ddevault>
what's bizzare is none of the other external symbols seem to cause an issue
<ddevault>
any ideas?
<ddevault>
what's even more bizzare is that I have an almost identical file for a RISC-V target which as builds just fine
mahmutov has joined #osdev
<ddevault>
update: friend cannot reproduce with binutils 2.37, I'm using 2.38
<ddevault>
but, more importantly, it doesn't look like Linux sets this at all
<ddevault>
so I suspect I can get away with zeroing it
<ddevault>
still can't get it to boot, though
<mrvn>
don't you have a primitive to hold multiple looks that is deadlock resistant?
terminalpusher has joined #osdev
<mrvn>
Maybe held locks should be like exceptions with "noexcept". Any function called when holding a lock must be nolock.
<mrvn>
Kind of reverse logic to exceptions. If the parent takes a lock the child must not lock.
elastic_dog has quit [Quit: elastic_dog]
elastic_dog has joined #osdev
mahmutov has quit [Ping timeout: 256 seconds]
mahmutov_ has joined #osdev
eroux has joined #osdev
nyah has joined #osdev
patwid has joined #osdev
gog has joined #osdev
<ThinkT510>
klange: I notice the github page for bim mentions syntax support. I see rust in the list it doesn't seem to be an option in :syntax
Oli has joined #osdev
hegz has joined #osdev
<heat_>
ddevault, how does your linker script look like?
<ddevault>
doesn't matter, this happens before the linker is even involved
<ddevault>
but I've closed the book on this problem for today, will dig further another time
<heat_>
that makes zero sense
hegz has quit [Ping timeout: 240 seconds]
<heat_>
maybe you're compiling it wrong?
<ddevault>
evidently.
terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #osdev
terminalpusher has quit [Remote host closed the connection]
<ddevault>
I suspect a binutils regression
<heat_>
very unlikely
hegz has joined #osdev
<ddevault>
it's never the compiler until it is
<ddevault>
if the same program builds on version A and not on version B and A < B, that's a regression
<hegz>
would a brainfuck compiler be a good project for starters?
<j`ey>
ddevault: godbolt supports binutils, would be an easy way to test
gwizon has joined #osdev
<ddevault>
not the right versions, though
<ddevault>
easy enough for me to build it myself
<ddevault>
will look into it later
<heat_>
source>:26:8: error: symbol '_data' can not be undefined in a subtraction expression
<heat_>
there ya go
<heat_>
clang is a bit more helpful
<ddevault>
thanks! but that doesn't explain why it works on binutils 2.37
<heat_>
it actually fails with every binutils there is in godbolt
<heat_>
they don't have 2.37, but 2.36.1 and lower, + trunk
<heat_>
hegz, what does a brainfuck compiler have to do with osdev?
heat_ is now known as heat
[itchyjunk] has joined #osdev
<mrvn>
hegz: a beginer will have no idea what brainfuck is, no ability to judge if it works right or even write hello world.
<mrvn>
ddevault: handing symbols from different sections in binutils is tricky or impossible. clang can do a bit more there.
<mrvn>
ddevault: using small or large memory model affects this too
ElectronApps has quit [Remote host closed the connection]
<gog>
heat: clang caught a bug for me that gcc missed entirely
<gog>
i'm warming up to it tbh
<mrvn>
gog: I think what you really want to do is have the Makefile build your code with both.
<gog>
simultaeneously or optionally?
<hegz>
heat: I'm not sure if offtopic is not allowed here, but guide me to a proper channel incase.
<hegz>
mrvn: well, the instruction set is simple and the parsing doesn't require an AST afaik
<mrvn>
gog: while developing it seems wastefull to try both. If one fails the other probably fails too. Especially if you can build in parallel with just one.
<ddevault>
mrvn: linux has a little C program to patch up these values in the header
<ddevault>
I might just end up writing something similar myself
<ddevault>
more likely I'll give up and use multiboot
* ddevault
spits
<mrvn>
ddevault: writing your own bootloader is a waste of time if your goal is writing a kernel.
<ddevault>
as far as I'm concerned, building a UEFI binary does not count as writing your own bootloader
<ddevault>
I don't intend to actually write a BIOS bootloader
<mrvn>
ddevault: true. It's just a bootstrap chunk to get to virtual memory.
<mrvn>
ddevault: My argument against it is that it requires 2 toolchains, or at least 2 different uses of the tools. The efi -> grub -> multiboot chain only needs ELF. Makes it easier.
<ddevault>
I just really hate grub, mrvn.
<mrvn>
one of these days I will have to do it anyway, just to get experience with it.
<ddevault>
I am willing to endure some (finite) degree of suffering to avoid grub
<mrvn>
ddevault: it works, never touch it again. There are alternatives that still use multiboot.
<kingoffrance>
hegz, there are proglangdesign and a quiet #compilers. i dont think anyone is criticizing, just how to get from point A to point B (OS)? will it be used to write an OS?
<Mutabah>
I use pxelinux and mboot.c32
<Mutabah>
works well enough
<gog>
with clang you only need one
<ddevault>
anyone who writes a kernel in brainfuck gets a beer from me
<mrvn>
hegz: you could frame your question differently: Like: Would writing a kernel that gives the user a brainfuck prompt be a good exercise?
<gog>
writing the kernel _in_ brainfuck? idk
<ddevault>
it can be done!
<gog>
that's a lot of <<>>>>+
<mrvn>
gog: you still have to figure out all the different compiler and linker flags though.
<ddevault>
programs are just one thing done after another, gog
<gog>
i know what a program is
<ddevault>
/s?
<gog>
always :p
<ddevault>
obviously it wouldn't be practical
<ddevault>
but it probably wouldn't even take that long
<gog>
i don't know what a computer is though
<ddevault>
I bet you could multiboot to a framebuffer playing snake in brainfuck in a few weeks if you already grok kernel hacking
<Mutabah>
How much wrapper assembly logic would you allow?
<ddevault>
only what is required
<gog>
i guess the fact that a brainfuck interpreter can be written in a rather short brainfuck program tickles my fancy with self-optimizing kernels
<FireFly>
I mean, does it count if I compile an existing kernel to brainfuck,
<ddevault>
points will be awarded based on the number of lines of assembly, higher scores are worse
<mrvn>
ddevault: you mean bottles of beer will be deducted for each line of assembly=
<mrvn>
?
<ddevault>
right
<ddevault>
that's what I said
<gog>
i don't drink beer tho
<mrvn>
gog: it's meta beer, replace with treat of choice.
<gog>
a conceptual beer
<hegz>
kingoffrance: I'll take a look at these, thanks. Wasn't really asking in context of OSDev though.
<hegz>
mrvn: I get it, gotta stay on topic
<mrvn>
hegz: For beginners you might want to look at scheme. The full language specification comes on 6 pages of easily readable text. And you can really do something with it.
roan has joined #osdev
<gog>
i'm gonna write a C++20 compiler
<roan>
How does an operating system get notified when there's a memory access in a userspace program to convert it via the pagetable?
<hegz>
mrvn: yeah, scheme seems more realistic than brainfuck tbh. I'll look into it.
<j`ey>
roan: the CPU does the conversion
<roan>
Oh so it's implemented in hardware?
<Mutabah>
Yes.
<j`ey>
by the MMU
<gog>
roan: on x86 a page fault happens if there's no mapping or the type of access is not permitted by the mapping
<roan>
Okay, thanks!
<gog>
other architectures with mmu work similarly
<mrvn>
roan: Some hardware can do it (or always does) in software with only a cache for recently translated addresses for speeds sake.
<gog>
yes there are some softmmu arches
<mrvn>
ppc for example is a mix
<mrvn>
arm has some of that too but it's not quite clear from the specs how to use it
<mrvn>
The c++ grammar is so broken they had to come up with a rule: If it looks like a function declaration then it is a function declaration.
<heat>
why is it not locking??
<mrvn>
heat: hehe, that one rocks too
<mrvn>
doesn't gcc/clang warn about ignoring the result of the constgructor there?
<heat>
did they add [[nodiscard]]?
<mrvn>
implementation defined
<mrvn>
i believe all the __attribute__ stuff now works in [[]]
<heat>
no
<heat>
some stuff is under [[gnu::]] I think
<heat>
but for instance, [[used]] doesn't work
<mrvn>
heat: yes
<heat>
ok, weird thing I just found out about: scoped_lock can take multiple locks
<mrvn>
foo.cc:2:21: warning: ‘nodiscard’ attribute can only be applied to functions or to class or enumeration types [-Wattributes] 2 | Foo() [[nodiscard]];
<mrvn>
heat: but that's returning the struct, not constructing it and throwing it away
<heat>
right
<heat>
well, crap
<mrvn>
If you add "S{};" somewhere it gets ignored
<heat>
yea
<mrvn>
How do you add nodiscard to a function? Seems to get ignored no matter where I place it
xenos1984 has joined #osdev
<mrvn>
__attribute__((__warn_unused_result__)) works on other methods but gets ignored on constructors :)
<mrvn>
Guess you have to keep using a linter to catch std::scoped_lock{lock}
<mrvn>
ignored as in you get a warning about ignored attributes
<Griwes>
warn_unused_result is also not suppresable with a cast to void if I have my attributes straight
<mrvn>
one can hope
<Griwes>
you can put [[nodiscard]] on *types* too
<mrvn>
Griwes: see above, doesn't warn for Foo{}
<mrvn>
The constructor doesn't seem to be seen as returning something
<Griwes>
clang does warn for that
<heat>
clang is always superior
<mrvn>
Griwes: for the original std::scoped_lock{lock} too?
CaCode has quit [Quit: Leaving]
<Griwes>
we don't seem to have added nodiscard on the lock types
<mrvn>
Griwes: too bad, half there.
<Griwes>
I believe that stdlibs are allowed to add [[nodiscard]] as they wish though
<Griwes>
sooooo file stdlib g
<Griwes>
file stdlib bug reports*
<Griwes>
and I'm going to immediately do that in my stdlib for the os, while I remember
<heat>
I think clang-tiny checks for scoped_lock
<heat>
tidy*
<heat>
does the sp not map to a GPR in arm64?
<j`ey>
no
<j`ey>
SP is x31, which is also xzr
<j`ey>
the zero register
<heat>
huh?
<heat>
so you're saying x31 is 3 registers?
<j`ey>
xzr is hardwired to 0
<j`ey>
just 2
<j`ey>
either sp or xzr
<heat>
wtf
<heat>
depends on the instruction?
<j`ey>
yep
<heat>
how?
<j`ey>
it says in the docs if it's sp or xzr
nyah has quit [Ping timeout: 272 seconds]
<heat>
strw x31, mem
<heat>
is this sp or zero?
<klange>
it took six hours of runtime, but the pi did hit the deadlock and spat out my debug message so I can reasonably assume it is actually a dead lock and not the pi randomly deciding to stop, yay
<klange>
so I threw a bit more debuggery at it, and we'll give it another six hours
<klange>
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)
<heat>
j`ey: what does any of that mean?
<j`ey>
heat: lol
<j`ey>
that's the description for the register offset store
<j`ey>
<Xt> is the data reg, Xn|SP is the memory reg
<j`ey>
the rest is unimportant for now
<j`ey>
but it says Xt so that means it's the zero reg,
<j`ey>
but for Xn it says Xn|SP
<j`ey>
so if you had: str x0, [x31].. that would actually be str x0, [sp]
<heat>
so in instructions where x31 is sp it would say <Xn|SP>?
<j`ey>
ye
<heat>
ah
<heat>
nice
<j`ey>
you'd never(ish) want to have zero as the memory operand, but you do want sp
<mrvn>
can you read the stack on aarch64 at all?
<j`ey>
what do you mean?
<klange>
yes, many many instructions let you use sp where an integer register is accepted
<klange>
important relevant quote from the ARM ARM:
<klange>
> 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).
<mrvn>
So to store the SP you have to e.g. x0 = SP + 0; *mem = x0?
<j`ey>
yes
<heat>
crin
<heat>
ge
<heat>
why can I not link with crtbeginS.o?
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<heat>
error: relocation overflow in R_AARCH64_CALL26
<mrvn>
wrong memory model?
<heat>
i don't think so? I'm using mcmodel=small and linking at -2GB
<mrvn>
and the crtbeginS.o is further than 26bit away.
<heat>
and that's impossible
<heat>
my kernel is not that big lol
<mrvn>
unless the crtbeginS.o is too big or has some section you don't map to -2GB properly
<mrvn>
looks like you are missing some other crt*.o
<heat>
actually I probably don't want to link against crtbegin/end
<mrvn>
You want to, just not that flavour. Your libc should provide that stuff.
<heat>
do, I don't
<heat>
no*
<heat>
I have init_array and fini_array support
<mrvn>
are you linking your kernel or apps?
<heat>
kernel
<mrvn>
well, doh, no crt for the kernel.
<heat>
and I don't link with libgcc, just compiler-rt
<heat>
(that I compile myself)
<heat>
I do have a crt for the kernel :)
<heat>
the weak functions I'm missing are provided by libgcc but not compiler-rt
<mrvn>
like udivmod?
<heat>
__deregister_frame_info
<heat>
and friends
<mrvn>
stack unrolling and exception stuff then
<mrvn>
do you realy want to reimplement core libgcc functionality?
<heat>
no
<heat>
i ship the compiler-rt builtins in my kernel
Burgundy has quit [Ping timeout: 256 seconds]
<heat>
but no unwind, etc
<heat>
don't really need any of that
<heat>
and crtbegin/end isn't a thing on clang, so I also don't have that
<heat>
I was linking against gcc's crtbegin/end, but that's not working right now because it can't relocate to a call that's that far away, even if it's doing if (funcptr) funcptr()