klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #osdev
isaacwoods has joined #osdev
Burgundy has quit [Ping timeout: 240 seconds]
pretty_dumm_guy has quit [Quit: WeeChat 3.4]
nyah has quit [Quit: leaving]
isaacwoods has quit [Quit: WeeChat 3.4]
mahmutov has quit [Ping timeout: 256 seconds]
k8yun has quit [Ping timeout: 256 seconds]
ElectronApps has joined #osdev
jstoker has quit [Remote host closed the connection]
jstoker has joined #osdev
[itchyjunk] has joined #osdev
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
terrorjack has quit [Quit: The Lounge - https://thelounge.chat]
<heat> trying to port my gcc target to arm64
<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
<bslsk05> ​paste.sr.ht: paste.txt — paste.sr.ht
<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.
<gog> mrvn: true
<gog> but i've already done that work
<kingoffrance> https://wiki.osdev.org/What_Order_Should_I_Make_Things_In%3F alta lang is an archetype there :D
<mrvn> ddevault: that's not worth just one beer.
<bslsk05> ​wiki.osdev.org: What Order Should I Make Things In? - OSDev Wiki
* ddevault is three years into language design and 2 months into kernel design
<gog> idk i wouldn't want to code something as complex as a kernel in a language that's nearly impossible to sight-read
<ddevault> gog: comments
<mrvn> gog: whitespace
<ddevault> I wrote an IRC bot in brainfuck once
<ddevault> you /can/ write complex programs in it
<gog> an IRC bot doesn't have potentially dozens of entry points and side-effects
<mrvn> I know, I will write my kernel in: https://codewithrockstar.com/
<bslsk05> ​codewithrockstar.com: rockstar : home
<gog> seems like a stretch
<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
roan has quit [Quit: Lost terminal]
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 272 seconds]
X-Scale` is now known as X-Scale
srjek has joined #osdev
matrice64 has joined #osdev
CaCode has joined #osdev
X-Scale` has joined #osdev
matrice64 has quit [Quit: Textual IRC Client: www.textualapp.com]
gxt has quit [Ping timeout: 240 seconds]
X-Scale has quit [Ping timeout: 272 seconds]
X-Scale` is now known as X-Scale
Vercas has quit [Ping timeout: 240 seconds]
[itchyjunk] has quit [Read error: Connection reset by peer]
isaacwoods has joined #osdev
gxt has joined #osdev
Vercas has joined #osdev
wootehfoot has quit [Ping timeout: 256 seconds]
matrice64 has joined #osdev
gwizon has quit [Ping timeout: 272 seconds]
heat has quit [Remote host closed the connection]
heat has joined #osdev
masoudd has joined #osdev
hegz has quit [Ping timeout: 240 seconds]
matrice64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
epony has quit [Ping timeout: 240 seconds]
heat has quit [Read error: Connection reset by peer]
heat_ has joined #osdev
epony has joined #osdev
matrice64 has joined #osdev
bauen1 has quit [Quit: leaving]
<sham1> *yawn* good evening #osdev
<GeDaMo> Ahoy-hoy
<gog> howdy
matrice64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wootehfoot has joined #osdev
troseman has joined #osdev
mavhq has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
mavhq has joined #osdev
exec64 has quit [Ping timeout: 250 seconds]
exec64 has joined #osdev
ddevault has quit [Ping timeout: 250 seconds]
heat_ is now known as heat
sm2n has quit [Ping timeout: 250 seconds]
ddevault has joined #osdev
sm2n has joined #osdev
bauen1 has joined #osdev
gjnoonan has quit [Ping timeout: 250 seconds]
ptrc has joined #osdev
gjnoonan has joined #osdev
patwid has quit [Ping timeout: 250 seconds]
patwid has joined #osdev
mahmutov_ has quit [Ping timeout: 256 seconds]
mahmutov_ has joined #osdev
cb has joined #osdev
mahmutov_ has quit [Ping timeout: 256 seconds]
GeDaMo has quit [Remote host closed the connection]
<heat> i'm going for arm64, screw it
<j`ey> yay
<heat> i never got riscv's interrupt chip working but that's technically not part of the architecture
<heat> the arm arm is so much better than the riscv isa docs jeez
<heat> also, missed the abbreviations
<j`ey> make sure you have the gic docs too
<heat> aren't there like 3 gics?
<j`ey> versions? there's 4 now
<j`ey> up to gicv4
<heat> anyway, the gic isn't my priority right now
<heat> I want to get a grasp of arm64 assembly and the mmu first
<heat> if arm64 supports timer irqs without touching the irq chip I can even get to userspace without it, like I did for riscv
<j`ey> hm, I think you do need the gic for the timer
<heat> easily the most annoying part of arm64: translating arm64 to aarch64
<heat> my OS expects arm64 but toolchain stuff expects aarch64
<j`ey> just use aarch64 then!
<heat> no.
<heat> aarch64 is the worst name in the history of names
<heat> somehow beats EM64T
<heat> and IA32e
masoudd has quit [Ping timeout: 240 seconds]
<clever> j`ey: i dont know the exact details, but the bcm2711 can run with the gic disabled, and instead use the legacy broadcom irq controller
<j`ey> yes but dont do that :P
<heat> all I want in life is proprietary irq chips
<j`ey> then buy an M1 :P
<heat> they don't use the gic?
<j`ey> nope
<j`ey> use AIC
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
<j`ey> that took marcan a lot of RE, would have been a lot quicker if it was a GIC
<cb> aarch64 (apple arch 64)
<sham1> iArch64
<heat> IA64
<heat> no need to thank me, apple
Oli has quit [Ping timeout: 256 seconds]
<mrvn> lets make an mc68064, 64bit extension to m68k.
<kingoffrance> that sounds like a good scheme, just so there is no confusion, best to be orthogonal iarch64 os -> iarch64 os x -> iarch64os
<mrvn> i64os?
<heat> IA64OS
<mrvn> not confusing enough
<kingoffrance> someone told me there was a long long long serious proposal
<kingoffrance> not apple, but best to throw that in there somehow
<heat> uint128_t exists
<mrvn> kingoffrance: because we don't have intX_t since 99?
<mrvn> heat: may exist
<heat> you know what I really really hate?
<heat> short int, long int
<mrvn> kanguage nazis?
<heat> that's somehow better than typing int after short and long
<mrvn> heat: cooles translation unit ever: "unsigned;"
<heat> AH
<heat> fuck
<heat> unsigned alone is also horrible
xenos1984 has quit [Read error: Connection reset by peer]
<mrvn> heat: don't forget: std::string foo(); std::string foo(foo);
<heat> most vexing parse time
<heat> oh yeah
<heat> std::scoped_lock{lock}
<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]];
<heat> std=c++17?
<mrvn> So the constructor is not a function?
<mrvn> -std=gnu++20
<mrvn> g++ (Debian 10.2.1-6) 10.2.1 20210110
<heat> tf
Oli has joined #osdev
<bslsk05> ​godbolt.org: Compiler Explorer
<heat> you need to add it to the type
<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
<j`ey> heat: zero
<j`ey> STR <Xt>, [<Xn|SP>, (<Wm>|<Xm>){, <extend> {<amount>}}]
<j`ey> from the docs
<j`ey> klange: progress!
<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
<klange> omg it's beautiful
<mrvn> you are DOOMed
<mrvn> Is the middle one the idle task?
<mrvn> I like your top.
<heat> ok, it's trying to call WEAK UND functions
<heat> that's why it's not working
matrice64 has joined #osdev
<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()