osdev liveblog #563

I'm porting this from apionet.

r​aven[x]: it begins.
r​aven[x]: https://git.citrons.xyz/tinycc
o​live[x]: are you aware you can push directly to tinycc proper
r​aven[x]: what do you mean?
o​live[x]: they have a "mob" branch
o​live[x]: the idea is like wikipages
o​live[x]: anyone can push or so
o​live[x]: repo.or.cz has an explanation page somewhere
r​aven[x]: so, I could commit malware to the mob branch right now?
o​live[x]: https://repo.or.cz/h/mob.html
o​live[x]: plausibly
o​live[x]: just as one can add disinformation to wikipedia
o​live[x]: but that is easier to spot
r​aven[x]: that's true, but ugh.
r​aven[x]: the last actual commit to master was 8 years ago
o​live[x]: the tinycc maintainer is awol
o​live[x]: yea
r​aven[x]: I like the idea of "finished software" that stops receiving 
updates. everyone is always saying "dead project!!!1! it's not maintained!!!!"
r​aven[x]: however.
r​aven[x]: tcc is far from finished. that's why I'm working on it
o​live[x]: lots of Luanti mods are effectively "finished"
v​iba[x]: > I like the idea of "finished software" that stops receiving 
updates. everyone is always saying "dead project!!!1! it's not maintained!!!!"
v​iba[x]: im still trying to turn off the part of my brain that instantly 
discards things based on the last commit date
r​aven[x]: hm, ok, I'm kind of starting to get how this works in practice
r​aven[x]: 
https://repo.or.cz/tinycc.git/commit/d9a6d9aec058ec92c1ad19ccf9e7913bc8ea945f
o​live[x]: miu i can't see what's behind this link
r​aven[x]: 
https://web.archive.org/https://repo.or.cz/tinycc.git/commit/d9a6d9aec058ec92c1ad19ccf9e7913bc8ea945f


r​aven[x]: ok, I just pushed to the mob branch. hi mom
r​aven[x]: I did --unset-upstream so I don't accidentally do that.
r​aven[x]: because I can run git push sort of reflexively sometimes
r​aven[x]: this is kind of neat. I mean, it's a little scarier of an idea 
than wikipedia in my opinion.
r​aven[x]: because you can't put malware on wikipedia. at least, not easily.


r​aven[x]: I think it would be interesting to try to take the pseudocode in 
architecture manuals and create an interpreter for it
r​aven[x]: thus deriving an emulator directly from the specification


r​aven[x]: the assembler does not support PC-relative ADR or LDR. evidently 
these aren't needed in the C compiler. the relocations they require are not 
implemented in the linker, so to implement them, I'll have to touch the linker
r​aven[x]: however, actually, that makes me wonder what it does instead.
r​aven[x]: the limited featureset of the linker implies that you'd probably 
have trouble linking code generated by other compilers
r​aven[x]: ah. I see.
r​aven[x]: you can just do ldr r0, [pc], offset
r​aven[x]: um, yes, so, it puts the constant in the middle of the code, loads 
with pc as the base register, and then jumps over the constant
r​aven[x]: that seems at least somewhat suboptimal
r​aven[x]: nonetheless, I suppose I could use the same approach in my 
assembler code and avoid hacking on TCC anymore
r​aven[x]: because although I think it would be very worthwhile to improve 
TCC, it's distracting from the project I'm using TCC for.
r​ebecca[x]: what's the project?
r​aven[x]: I've contracted osdev disease again.
r​aven[x]: I want to make my operating system with TCC, so then I can port 
TCC to my operating system, and then have it be selfhosting.

my first target is raspberry pi 3/4

the raspberry pi's firmware loads a flat binary into memory. it doesn't understand ELF images or anything; it just starts executing from the beginning. the osdev wiki tells you to use GNU linker scripts, but as I am not using binutils, I'm going to use the advanced linker called "cat."

I'm going to have a tiny loader that is compiled as a flat binary. an ELF image of the kernel will be concatenated to the end of it. the loader will peek into the ELF header, hollow out .bss, and jump into the entry point.

if I understand how ELF images work correctly, this should work.

ok, well, I've been staring at objdump output, not necessarily understanding what it all means, and I think it might expect me to map things where they don't end up necessarily just by blindly copying it into memory.

if I can't make this work easily, it might actually just be better to have my entire kernel be a single compilation unit, compile it all as a flat binary, and presumably everything will appear in the order I specify it.

I wonder, actually, if I could have separate compilation units, but name the unit containing the init code alphabetically before the others. that would be such a nasty hack, haha.

if you're eschewing binutils and friends, what's the advantage of using elf images as opposed to flat binaries or some custom format?

because TCC emits ELF

it can also emit flat binaries, but it's unclear where the entry point is. of course, that can be solved by my "having everything be in one compilation unit" idea, which I'm starting to think would be a good idea, especially considering TCC's breakneck compilation speeds.

a reasonable question would be: "how are you going to write an entry point in assembler if you're compiling everything as one C compilation unit?" of course, the answer to that is that mercifully and quite conveniently, TCC supports asm at the toplevel.

you know, I'm actually pretty sure that if I just specify the entry point object file first in the command line arguments, it will probably put that first in the file in the beginning of the output. I'll just try doing that.

nope, I'm totally wrong. it did not do that.

also, the file has a ton of extra empty space for some reason

I specified my init code as the first argument to the linker, but the first thing that appears in the file is a string literal.

hm, it seems that the code starts at 0x90000. indeed, my entry point is ordered before everything else, but only after kilobytes of data and zeros

oh! putting my init code is a separate section (I called it .text.init) does put it at the start of the file.

but only after kilobytes of data and zeros

what could possibly cause this?

alignment