<geist>
i always provide all of my own stuff for that
<geist>
easy enough to do, just look at what crtbegin does and do it yourself. it's not much
<innegatives>
ok thanks
<geist>
plus generally want to very carefully control when/how that is done in a kernel vs a regular program
<geist>
for calling things like constructors and zerong bss, etc
<geist>
but the mno-red-zone thing is absolutely needed
<innegatives>
you patch gcc 12.1.0 with redzone flag, but scripts pull 12.2.0, is it not needed in 12.2.0?
<innegatives>
i mean the patch
<geist>
yah just meant the patch applied cleanly so didn't bother updating it
<geist>
i actually have a WIP branch for 13.1
<geist>
also really, on x86-64 you probably dont even need libgcc.a. there's very little in it that you will tend to find on that particular architecture
<geist>
some other arches may need it more, depending on what sort of stuff you write
<geist>
(ie, lots of 64bit math on 32bit only cpus, or divides on cpus that dont support divide)
<geist>
but x86-64 is full featured enough that there's usually an instructon for what you want, so no need to emit an outcall to libgcc
<geist>
it almost kinda makes sense to leave it out so you know exactly what it's trying to use when you get a link failure
xenos1984 has joined #osdev
<innegatives>
im not that good, im just trying to get my cpp global constructors to work
SGautam has quit [Quit: Connection closed for inactivity]
<bslsk05>
github.com: lk/main.c at master · littlekernel/lk · GitHub
<geist>
the key is to look at the linked binary and see what the constructor list symbols are
<geist>
i think there are various ways they can come out, and it depeds on the linker script
<geist>
but usually you end up with a ...start and ...end symbol, and the gist is you just iterate through a list of fucntions and call them
<innegatives>
so i dont need to link crt stuff?
<gog>
i told you last night that in-kernel you'll need to roll your own
nyah has joined #osdev
<innegatives>
how come meaty skeleton in osdev and other articles just tell you to link crt stuff? are they wrong?
<gog>
the implementations provided by gcc are hosted
<gog>
it rolls its own
<gog>
crti.s
<innegatives>
thats what you mean by rolling your own? those 10 lines of asm?
<gog>
but i see it also links to crtend.o and crtbegin.o
<gog>
i don't know why it does but it's also not something i would do
<geist>
innegatives: yeah that's what i told you a while ago, dont link the crt stuff, just do it yourself
<innegatives>
ok will try
<geist>
remember not every osdev tutorial is holy. it's just whatever some person did that day
<geist>
there are a million ways of doing everything, some are compromises to avoid other problems
<geist>
in this case i'd just do it myself because it's pretty easy, and i want to control precisely where the constructors are called, and then i dont depend on exactly what you're talking about with mcmodel=kernel, etc
<geist>
so it's a tradeoff. i do it myself, which is some extra work, but then it's a stable interface so it's not going to break on me randomly
<innegatives>
my linked kernel doesnt have any symbols like ctor_list or such
<geist>
right, thats what i was saying you might need to look at the symbol list of your kernel and see what they're called
<geist>
there's probably a pair of symbols for start and end
<innegatives>
i mean it doesnt have anything resembling that
<geist>
depends on what linker script your using
<gog>
the generated code might slap them in .ctors and .dtors and your linker script should put them in the right place
<geist>
do you have any global constructors?
<gog>
with symbols bordering them
<geist>
right
<gog>
or rather, you will need to edit your linker scrip tto do so
<bslsk05>
github.com: lk/kernel.ld at master · littlekernel/lk · GitHub
<geist>
i dont know what linker script you're using, or if you're using the default ones, what the default name is
<geist>
suggestion: dont use global constructors, they're really dangerous
<geist>
it's kinda a hand grenade you're holding there
<innegatives>
geist: do you use them in lk? if not why you have ctor init code?
<geist>
the core system doesn't use them, but i can't control if someone links in some C++ and wants to use them
<geist>
so i provide the functionality
<innegatives>
I was hoping to have a global Console instance so different systems can log without being passed a dependency. Is the non-dangerous way to pass the Console down from main to all the other subsystems?
<innegatives>
geist: some other day someone here told me that all i need to be aware of as far as cpp goes is this list: https://wiki.osdev.org/C%2B%2B
<bslsk05>
wiki.osdev.org: C++ - OSDev Wiki
<innegatives>
is there more to it?
<geist>
oh i dunno, i dont particularly want to read that wall of text
<geist>
probably. C++ never ends.
<geist>
but i saw your makefile and you're turning off a lot of features so thats good
<geist>
but again i wouldn't really recommend trying to write a kernel unless you're at least moderately experienced in it
<geist>
especially given that there are lots of things that if you're not aware of, *by omission* you'll have problems with
<geist>
ie things you dont know you dont know cause problems with it
cultpony has joined #osdev
<geist>
that page seems to cover just the basics, none of the hazards of the language itself
<geist>
more like run time support
<geist>
flip side is, well if you want to learn the details probably not a bad idea
<innegatives>
ok thanks
<innegatives>
ill stick to it for a while
<geist>
er the sentence aove where i said dont write a kernel i mean 'dont write a kernel in C++'
<geist>
writing a kernel, go for it, i totally approve
<geist>
just first time doing a kernel plus first time really dealing with low level details of C++ is a double whammy
<heat>
aw fuck i have the GREATEST NAPS
<geist>
grats!
<heat>
geist, fyi crtstuff is usually PIC..... gcc doesn't do it by default because they're smelly poopies
<innegatives>
geist: like you said, define global pointer and init the constructor yourself, but for that I assume I need a heap impl?
<heat>
but my hosted GCCs, etc, they all have PIC crtbeginS.o and crtendS.o
<geist>
innegatives: not for placement new
<heat>
not that I entirely recommend linking those two object files in, but it Just Works
<geist>
innegatives: look up placement new. it's a special kind where you feed it a void * of the memory to run the constructor on
<heat>
it's the least-conflict solution that covers the most ground. this entirely stops working once you realize clang does not have the objects, and only does init_array
<heat>
because global initialization is freaking hard
<geist>
heat: i think it's not that its PIC, it's the whole mcmodel=kernel stuff
<innegatives>
geist: sorry for noob questions but where do i get this void* region of memory from?
<geist>
innegatives: you can declare an array of bytes next to it
<heat>
geist, PIC compiles fine for -2GB code
<geist>
ie *basically* (though not exactly) something like
<heat>
erm, links fine
<geist>
heat: then take it up with innegatives
<sham1>
With the normal caveats about things like alignment applying
<heat>
I do distinctly remember that crtstuff is not PIC by default, it's what I'm saying
<geist>
innegatives: char bytes[sizeof(foo]]; new (bytes) foo; or something like that
<geist>
off the top of my head
<geist>
and yeah what sham1 said
<geist>
it gets complicated, but that's C++
<sham1>
You need something like std::aligned_storage, but basically that
<heat>
and bare metal x86_64-elf only does defaults...
<geist>
sham1: yeah but doesn't have std:: so it's whatever the underlying thing s
<sham1>
You can't go out there and just cause undefined behaviour with placement new
<sham1>
I'd rather the C++11+ standard thing of alignas
<geist>
yeah i ten to prefer the old ones but have been mostly forced at work because code styles to adopt all the new c++ ones
<geist>
and starting to dig it
<heat>
i think i use this trick like twice through the whole kernel
<heat>
it's majorly useless
<sham1>
Of course, once you have an aligned storage thing like that, you can then build an equivalent to `std::variant` and get some very nice stuff out of that
<geist>
we have a wrapper thing in zircon that makes it kinda nice, also nukes the deconstructors which is nice
<innegatives>
geist: but then don't I need to impl "new"? Which would mean I need to impl malloc?
<geist>
innegatives: no. that's why i said look up placement new
<geist>
it's not what you think
<innegatives>
ok
<geist>
there are multiple types of new. *you* have to provide the implementation of
<sham1>
Well you have to "implement" placement new, but it's trivial
<geist>
but placement new is special because it doesn't rely on a heap
<geist>
it simply passes the void * you give it to the constructor
<geist>
whereas the 'normal' news you will need to also provide an implementation that calls through to a heap
heat has quit [Read error: Connection reset by peer]
<innegatives>
it just says that "no matching function for call to "operator new(...""
<bslsk05>
fuchsia.googlesource.com: zircon/system/ulib/lazy_init/include/lib/lazy_init/internal/storage.h - fuchsia - Git at Google
<sham1>
That's one of the tricky things with doing something like a `myos::variant`
<heat>
also you need to explicitly call operator=, ~class() for dtor, etc
<innegatives>
one more noob question, declaring "Console *console" global pointer in my console.hpp leads to multiple definitions error (i do have guards), I init it with placement new in my kernel_main, where should I put the global pointer to be accessible everywhere without getting multiple defs error?
<sham1>
Or `myos::expected` because you of course want to have errors without exception stuff
<geist>
ah i see. it doesn't do a byte array, it just unions the object with an empty struct so that it doesn't get the constructor automatically run
<sham1>
innegatives: extern the global pointer in the header and then define it in kernel_main
<geist>
thus auto handles the alignment/size stuff
<innegatives>
ah ok nice
<heat>
the gang figures out C++ while writing a kernel in C++
<sham1>
Twitch writes OS
<sham1>
But yeah, once you have a heap, C++ does become a bit easier but you still have to deal with not having exceptions
<innegatives>
how the hell did you guys learn all this crap
gmacd has joined #osdev
<heat>
heroin
<geist>
time
<sham1>
Through sheer stupidity of spending so much time doing this kind of stuff
<heat>
i have dedicated soooooooooooooo much time to my stupid fictional bad UNIX
<geist>
or beig forced to because work
<geist>
some thing si'm more interested in than others, but programming language details are fairly low on my list
<geist>
but getting good codegen/performance/etc out of the language i have is high on the list, so lots of times i'm more or less forced to grok the details or i dont feel good abou tit
<sham1>
I just like language lawyering
<sham1>
I do it with C as well
<geist>
yah i precisely dislike language lawyering. mostly because it's a neverending battle at work, and i let others do it
<geist>
also makes it hard to actually like commit code if you have too many LLs around
<geist>
much like real lawyers i guess
<morgan>
i used to be able to language lawyer the hell out of C89 and now i've forgotten half of it 'cause I haven't written any C in five years and i'm much happier
<sham1>
Sometimes the wiki has annoying amounts of UB in the example code, but oh well, it's just example code. One is better off rewriting it anyway
<geist>
word.
<geist>
sometimes it's better to teach with simpler, less perfect code, than to try to force someone new to undestand the complete wall of details, and thus they dont really learn
<sham1>
Right and okay, for some "minor" UB like unaligned pointers I'm not too harsh, although it still hurts my soul, but then there are some things that just annoy me
<sham1>
For example, casting just random pointers into pointers to structs. *That* grinds my gears, and sure, for things like for example multiboot stuff it's unavoidable, but still
<geist>
but knowing when to bite your tongue is important
<geist>
otherwise people stop listening
<geist>
i think when teaching new folks the key is to introduce things in layers of complexity
<sham1>
Right
<sham1>
Other minor things are the use of packed structs with things like the GDTs and bitfields in general but again I do get that those do have utility as far as education is concerned
<geist>
yeah i'm a bit torn about that. i generally dont like using bitfields for that sort of thing if nothing else because it's hard to tell when you're modifying a bitfield vs a full word. the ABI issue of how the bits are laid out i'm not as worried about *if* it's arch specific (like the GDT)
<geist>
as in the compiler wont/cant really change that layout without an ABI change anyway
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
<sham1>
C++ famously has had a stable ABI :P
<sham1>
Like okay, bitfields changing probably isn't that big deal since it's also inherited from System V ABI for C, but still
wootehfoot has quit [Read error: Connection reset by peer]
<sham1>
One of the reasons I'm so enamored with micro- and nanokernels is that they let you get away from kernel space and into a (slightly) saner territory faster
goliath has joined #osdev
heat has quit [Ping timeout: 250 seconds]
heat has joined #osdev
<innegatives>
Can someone please tell me why I get this error when compiling this: (text+0x330): relocation truncated to fit: R_X86_64_PLT32 against symbol `isr_handler' defined in .text section in ./idt.o https://github.com/jafarlihi/mepsitahl
<bslsk05>
jafarlihi/mepsitahl - [WIP] x86_64 OS (0 forks/0 stargazers/MIT)
<innegatives>
Is it because I link kernel to higher half?
gmacd has quit [Ping timeout: 250 seconds]
<innegatives>
ah shit i fixed it
awita has quit [Ping timeout: 250 seconds]
<gog>
hi
<sham1>
hi
<gog>
what's shakin
innegatives has quit [Quit: WeeChat 3.8]
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<geist>
sham1: right, that's my point. the layout of structs/etc is very much specified by the arch, at the C level
<geist>
doesn't change much
<geist>
if it did everything in the planet would break
<geist>
name mangling, etc was a bit more flexible over the years
johnjaye has joined #osdev
<lav>
gog: Shakin is a village in Dodangeh-ye Sofla Rural District, Ziaabad District, Takestan County, Qazvin Province, Iran.
awita has joined #osdev
<heat>
geist, isn't it possible you kind of painted yourself into a kernel with the whole "expose vm objects" thing to userspace?
<heat>
it seems like you're exposing way too many internal details to ever be able to change the inner workings significantly
innegatives has joined #osdev
<geist>
it's a thing i've thought about a lot
<geist>
there's some amount of abstraction there that's not obvious, and it's more of a polymorphic thing: the vm object may be a this or a that but you treat it like it's a container of bits
goliath has quit [Quit: SIGSEGV]
johnjaye has quit [Quit: WeeChat 4.0.0-dev]
immibis has joined #osdev
<innegatives>
does osdev get easier once you are done with the initial hurdles?