<bslsk05>
github.com: bootstrap/mem.c at master · zid/bootstrap · GitHub
<mrvn>
zid: I have a bunch of pages in .bss that I initialize the memory pool with and then parse the memory map.
<mrvn>
poyking16: what compiler are you using that the code compiles at all?
<poyking16>
clang
<gog>
you can do pointer arithmetic on void* as a gcc extension
<gog>
it's not a great idea tho
<gog>
gcc implicitly does it as char*
<gog>
but that's still bad because size of void is not 1
<zid>
C99 on the streets, gnu99 in the sheets
<gog>
it's undefined
<mrvn>
ahh, you don't name the struct "PACKED" but that is some secret define for __attribute__ (("packed"))
<zid>
void * arith is *very* helpful for reverse engineering decompilation and that's about it :P
<poyking16>
I was just trying to write a temporary solution that I could then rewrite in a better way later
<poyking16>
yes PACKED is a define in another hader for __attribute__((packed))
<mrvn>
you never want to use packed
<poyking16>
why
<gog>
IDB
<mrvn>
it generates slow code
<poyking16>
some of the structures have to be packed such as the paging structures and the structure that converts between virtual addreses and indexes into the paging structures
<mrvn>
You should only use it to read file data and then unpack it or pack it wand write file data. In which case you can just memcpy into a buffer directly.
<mrvn>
poyking16: they don't.
<mrvn>
Case in point: level4_addr should be using uint64_t. No packed needed.
<poyking16>
level4_addr is used to get the indexes for the paging structures
<gog>
you can do bit twiddling to get that
<poyking16>
it makes it more readable
<gog>
it makes what's happening more opaque
<gog>
and implemention defined
<gog>
more readable symbolically but more inscrutable operationally
<mrvn>
Last I compared it (gcc-8) it using bit shifts + mask also generated better code.
<j`ey>
poyking16: get used to reading bit masking code :P
<gog>
bit twiddling is good actually
<gog>
hiding it behind compiler magic doesn't mean it's not there
<mrvn>
poyking16: you can use bitfields as long as you keep in mind that they are implementation defined. You might have to reverse the order of fields depending on the compiler.
<poyking16>
I didnt know that the order depends on the compiler
<mrvn>
Does latest C have [[gnu::packed]]?
<poyking16>
I dont think so at least upto C11
<mrvn>
poyking16: your 2 codes do something completely different
<mrvn>
ctx->level4+ctx->koffset
<mrvn>
PML4E *level4;
<mrvn>
+ on void* and PML4E* are not the same.
<moon-child>
mrvn: fine to use packed if doing your own alignment
<moon-child>
not because 'smaller is better!' but that's a strawman to begin with
<zid>
OS code *is* one of the few places you can use packed, but this isn't a struct
<zid>
it's a u64 where some of the bits can be interpreted with a different meaning
<mrvn>
moon-child: no. packed means the compiler might have to read/write everything as bytes.
<zid>
moon-child: Didn't we figure out that gcc is fucking useless with bitfields in ##asm the other day?
elastic_dog has quit [Ping timeout: 272 seconds]
<zid>
and it doesn't understand that OR and xor etc don't change the other members
<zid>
so it flushes the entire thing
<mrvn>
zid: gcc-8 is horrible with it. not sure if that has changed
<mrvn>
moon-child: On ARM gcc by default assumes the CPU doesn't do unaligned read/write so you do get byte read/write for anything packed. Clang assumes the cpu is set to allow unaligned access and bombs when your kerenel doesn't set the control bit
<poyking16>
I will rewrite the code and hopefully there wont be many problems
<mrvn>
And forget about taking the address of members of a packed struct.
<mrvn>
poyking16: remove all the packed and define your bitefields using uint64_t.
pretty_dumm_guy has joined #osdev
<mrvn>
poyking16: and you should use uintptr_t when doing arithmatic on addresses
elastic_dog has joined #osdev
<mrvn>
asm volatile("mov %0, %%rax;" "mov %%rax, %%cr3;" : : "r"(ctx->level4) : "%eax"); why do you trash rax?
<poyking16>
you can only move a register into cr4
<poyking16>
cr3
<mrvn>
%0 is a register, you used "r"
<mrvn>
And if you want the a register then use "a"
<poyking16>
I am not to good with C inline assembly
<mrvn>
you might also want to add "memory" because changing the page table changes everything
<mrvn>
don't want to write registers to memory, call paging_update to change address spaces and read register back from different memory and have the compiler optimize that out thinking you read the same memory.
<mrvn>
poyking16: Do you understad now why lines 60 and 61 are different?
<zid>
technically it's gcc inline assembly, it's not part of C at all
<poyking16>
what bootloader do you recomend
<mrvn>
anything that supports multiboot
<poyking16>
Is limine a good choise
<mrvn>
never head of it so probably not
gog has quit [Read error: Connection reset by peer]
<mrvn>
heard
<zid>
grub, ofc
<poyking16>
it boots your kernel into 64 bit mode and maps it to the higher half
<zid>
sounds annoying tbh
<zid>
because then you don't get to control your initial page tables
<poyking16>
Yes, that is why my code was somewhat messy
<poyking16>
I might try to write a 32 bit kernel before trying to port it to 64 bits
<poyking16>
but I got stuck trying to map the kernel to the higher half in assembly
<poyking16>
as I do not have much experience programming an assembly
<zid>
I do it in C using a weird split bootloader and kernel setup I launch via grub modules
<poyking16>
in
<zid>
that was what the repo I did earlier demonstrates
<zid>
it builds boot.bin and kernel.bin then makes grub boot.bin and it sets up 64bit paging and runs kernel.bin
<poyking16>
I think I might try that
<mrvn>
poyking16: getting into 64bit mode is a bit harder but after that 64bit is much better
<poyking16>
should I try and write a 32 bit kernel and then port it to 64 bits
<mrvn>
no
<poyking16>
should I write a 32 bit kernel at all
<mrvn>
only if you have systems that don't do 64bit.
<zid>
32bit kernels are kinda of annoying
<mrvn>
which for x86_64 is pretty certaionly a no.
<zid>
especially for x86
<zid>
64bit is less limiting and also the interfaces are simpler
<zid>
long mode just basically says "If in long mode, set all these fields to 0" in a lots of places
<poyking16>
like in segmentation
<zid>
and tss and some other stuff, yea
nyah has quit [Quit: leaving]
<mrvn>
Long mode also gives you a much more modern baseline that all cpus must have, like SSE. With x86 (32bit) where do you draw the line what you support? 386? 486? 586? cpus with cmov?
<poyking16>
I will write a multiboot 64 bit kernel then and hope it works
<mrvn>
Only CPUs with pae?
<poyking16>
I will probably get stuck on paging again
nyah has joined #osdev
<mrvn>
poyking16: have you tried the barebones example in the wiki?
<zid>
I did a few drafts myself
<poyking16>
as I understand the theory and how the cpu interprets the structures but actually implementing it is quit difficult as you need to find virtual memory to store the structures and without paging enabled using your custom maps accessing and storing the data becomes quite difficult
<zid>
and I still don't like my allocator, but it works
<zid>
it's fairly mind bending yea, full of catch-22s
<mrvn>
poyking16: 32bit or 64bit paging is fundamentally the same. It's just the bits that differ a bit.
<mrvn>
poyking16: page tables are a prefix (radix) tree with 9bit index per level. Draw it out as a tree for a few examples and any time you get confused draw it out. When you visualize it it really becomes easy.
<zid>
x86 is gross because it's hard to use, amd64 is gross because it's hard to boot :P
<mrvn>
ARM/ARM64 is gross because it's hard to "hello, world"
<poyking16>
I understand the way paing works but its mostly the actual creation of the structures on 64 bit
<heat>
everything is fucking gross
<heat>
go to riscv
<heat>
it's less gross
<mrvn>
riscv is gross because it's hard to buy
<heat>
but srsly though riscv64 is a good choice for a first arch
<heat>
really simple
<poyking16>
Maby it will be easier if I use grub and create the initial tables myself and are therefore able to control exactly where everything is placed in memory
<heat>
assembly is tough to write though, but so it goes in the risc world
<poyking16>
possibly making the initial mapping easier
<heat>
I've reached a point where I use C to write all that early boot/early page table code
<heat>
I feel reasonably confident that I won't fuck up
<heat>
I don't recommend it to newbs for that reason
<zid>
fuck writing it in assembly though
<mrvn>
I write that stuff in C, compile it to asm, cross check and twiddle the asm a bit and then use that.
<mrvn>
Needs a bit of fix up to be totally position independent if I want to boot on different ARM devices.
<heat>
I use super simple C without globals and whatnot
<heat>
sometimes, a function call
<heat>
but rarely
<mrvn>
poyking16: you might consider using C++. You can write your page tables in C++ using only constexpr/consteval and constinit the initial page tables so they land in .data as premade structures.
<mrvn>
heat: a function call needs a stack though
<heat>
you can get a stack
<heat>
in fact, you already have one if you're calling into C
<mrvn>
or you get lucky and it gets inlined and you don't need one before you go virtual.
<heat>
the entry point should be in asm
<poyking16>
I once tried to write a kernel using C++ but C++ has some fustrating elements that caused me to use C instead as the C++ kernel was extremly badly written
<mrvn>
poyking16: use freestanding, no rtti, no exceptions.
<zid>
That's normal for C++ software
<mrvn>
poyking16: with those 3 things you basically get a better C without the frustating things that are hard to set up initially.
<poyking16>
I prefer C as it is simple and C++ is more fustrating as it has a stronger typing system
<zid>
It wishes
<zid>
also, I wish C's were stronger
<Griwes>
C is simple, which leads to more complex code, don't @ me
<poyking16>
simplicity creates more readable code in most cases
<zid>
you weren't allowed to argue
<zid>
he knows he's wrong :P
<Griwes>
Simplicity of the code, yes. Simplicity of the tool means your code needs to be more complex to achieve more complex goals.
<Griwes>
Oh, I'm right, I just said not to @ me :P
<zid>
oh if that's how it works
<zid>
Griwes is wrong don't @ me
<zid>
QED.
<Griwes>
Wow, zid @'d me, something I expressly asked y'all not to do :p
<zid>
I did not.
<mrvn>
poyking16: with the exception of some keywords (like new) and pathological cases you can just compile your C code in C++. The stronger types are a plus and prevent errors. Like your pointer arithmatic not doing what you though it did.
<mrvn>
RAII is a huge benefit too
<mrvn>
Making a type safe List or other container in C is possible but oh so ugly to implement. Or writing something as simple as `max(a, b)`. A few limited uses of template makes a huge difference.
<poyking16>
I will probaby use C++ then
<poyking16>
but mostly for the templates
<poyking16>
as templates I agree are a very useful
SpikeHeron has quit [Quit: WeeChat 3.0]
<poyking16>
for generic containers
<poyking16>
make
<poyking16>
wrong terminal
lanodan has quit [Ping timeout: 244 seconds]
lanodan has joined #osdev
the_lanetly_052 has quit [Ping timeout: 268 seconds]
SpikeHeron has joined #osdev
eck has quit [Quit: PIRCH98:WIN 95/98/WIN NT:1.0 (build 1.0.1.1190)]
eck has joined #osdev
eck has quit [Client Quit]
eck has joined #osdev
<mrvn>
Learn something new every day: shared_ptr<void> p(new Foo());
<mrvn>
Yes, that works and is perfeclty sane.
<mrvn>
and does the right thing
wootehfoot has quit [Ping timeout: 252 seconds]
eck has quit [Quit: PIRCH98:WIN 95/98/WIN NT:1.0 (build 1.0.1.1190)]
eck has joined #osdev
<Griwes>
mrvn, not nearly as fun as the aliasing constructor ;>
poyking16 has quit [Quit: WeeChat 3.6]
<kof123>
pirch...now there's a name i havent heard in a long time
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
gog has joined #osdev
dude12312414 has joined #osdev
<PapaFrog>
BitchX just for the name!
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
liz has quit [Ping timeout: 252 seconds]
dh` has quit [Quit: bbl]
opal has quit [Ping timeout: 268 seconds]
GeDaMo has quit [Quit: A program is just a bunch of functions in a trenchcoat.]
opal has joined #osdev
<[NAME]>
mIRC. Bare. With no script packages.
kof123 has quit [Ping timeout: 268 seconds]
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
rwb has joined #osdev
rwb has quit [Client Quit]
rwb has joined #osdev
socksonme_ has quit [Ping timeout: 245 seconds]
[NAME] is now known as sbalmos
dh` has joined #osdev
opal has quit [Remote host closed the connection]
opal has joined #osdev
wootehfoot has joined #osdev
wootehfoot has quit [Remote host closed the connection]
<heat>
i need a poll
<heat>
S3 support or more arm64 bringup
<heat>
your choice developers of the operating systems
<j`ey>
I voted
rwb is now known as rb
<Bitweasil>
arm64!
<Bitweasil>
Who cares about suspend? :D
<Bitweasil>
... actually, me, but only about a quarter of my stuff will actually suspend/resume properly.
<Bitweasil>
ARM doesn't (but idle power is low enough I don't care), my house desktop (Intel) has stopped suspending for some reason, Qubes just won't do it reliably on any of my hardware. I guess some of my AMD compute boxes suspend...
<Bitweasil>
Oh, and my PineBook Pro is actually pretty good at it!
<heat>
j`ey, sorry, I'm not rewriting my OS into arm64-only rust
<j`ey>
heat: lame. then my vote is arm64 bringup
<heat>
now im kinda wondering
<heat>
does arm64 do S3?
<heat>
how does that work
<heat>
like SBBR platforms
<Bitweasil>
It's not S3, really.
<Bitweasil>
It's typically something through uboot.
<heat>
but SBBR platforms require ACPI
<Bitweasil>
And I believe the details are *exceedingly* platform specific.
<heat>
thus, S3
<heat>
in fact, ACPI and UEFI
<Bitweasil>
Oh, hm. Not familiar with anything that fancy, then.
<heat>
oh yeah, something cool I found out about today
<bslsk05>
arm-software.github.io: Embedded Base Boot Requirements (EBBR) Specification v2.0.1-8-gc90b128 documentation
<Bitweasil>
Oh hey, actually got the PDF to load.
<heat>
it seems that arm really is pushing for UEFI everywhere
<heat>
hence why uboot has uefi support these days as well
<heat>
something interesting is that ebbr doesn't mandate acpi nor dt
<heat>
sbbr mandates ACPI
srjek has joined #osdev
<heat>
also for some reason they also specify riscv details
<heat>
I think RISCV is working in tandem with ARM
<heat>
but yeah, UEFI everywhere baby
h4zel has joined #osdev
arch_angel has quit [Ping timeout: 240 seconds]
h4zel has quit [Ping timeout: 240 seconds]
<brynet>
OpenBSD recently got some initial support for suspend/resume on arm64, apparently a huge problem is actually finding a machine that has an actual wake mechanism, e.g: some kind of button.