<kof673>
i dunno, it boots in real mode doesn't it :D
<kof673>
not sure if it is supposed to work e.g. on a floppy...i only got text from qemu "-kernel" option so maybe my setup is badly broken...
<kof673>
and for zImage...something has to uncompress it ....what is that part written in?
<nikolar>
shoudn't gcc support some 16-bit x86
<kof673>
ia16-gcc does, another elks thing AFAIK
<zid>
I wouldn't wanna use it lol
<kof673>
but that is relatively new to my knowledge, not sure 1998 or earlier gcc did
<kof673>
2.7.2.3 is.........look up the date, but mid 90s is my guess :D
<zid>
you can't really write real mode x86 in C unless you use C-like and add near and far keywords and shit, realistically, for anything serious
<zid>
everybody used write 'serious' things in proper 32bit C and bundle dos4gw or whatever
<nikolar>
zid: ia16-gcc is for elks
bauen1 has joined #osdev
<nikolar>
and elks assums ss=ds
<nikolar>
so basically, you don't deal with segmentation
<mpetch>
Well there is OpenWatcom 2.0 C. Although dated it does real mode and segmentation well.
<zid>
BORLAND TURBO C++
<nikolar>
zid: does it also do c
<zid>
I'm not actually sure, but in that era, C++ just meant void * is broken and '' is the wrong size :P
<zid>
I think the way watcom did it was just that all pointers were far
<heat_>
wdym '' is the wrong size?
<ring0_starr>
why do you NEED near and far keywords in an implementation of C for the 8086
<zid>
it's char in C++ and int in C
<heat_>
huh, TIL
<zid>
That's literally half of what I know about C++
<zid>
because other than using 'class' as a reserved var name, it's what stopped C++98 being compatible with C
<nikolar>
int class; /* c++ contingency */
<mpetch>
Openwatcom C supports a variety of memory models in 16-bit code generation. It can use near and far. and what gets generated depends on the model.
ryoskzypu has joined #osdev
<kof673>
~500k uncompresssed Image (as opposed to compressed zImage). the release notes says there is some limit for uncompressed kernels, but they boot faster on old hardware? ...maybe it is hitting that limit, who knows :D
<zid>
yea it has model=small or whatever too
<ring0_starr>
no what i'm saying is that it shouldn't need different memory models at all
<zid>
but then you only gets a segment
<ring0_starr>
this is the compiler's job
<zid>
I'm not sure you could like.. annotate things for a 'mixed' environment?
<ring0_starr>
sure it might do stupid memory layouts but strictly speaking it should be able to do standard ISO C just fine
<nikolar>
i geuss everything is a long pointer
<ring0_starr>
right
<zid>
far
<nikolar>
far pointer
<zid>
unles -mcmodel=small equivalent
<ring0_starr>
ok fair enough
<nikolar>
or
<ring0_starr>
so what i described exists as a far memory model
<nikolar>
everything is a near pointer
<zid>
reight
<heat_>
char to int promotion is a biatch
gog has quit [Quit: byee]
ryoskzypu has quit [Remote host closed the connection]
<mpetch>
far pointers in dos were still limited to max 64KiB offsets. So creating objects of greater than 64KiB required extra work which is why the huge pointers were created. Unfortunately making everything a huge pointer adds considerable overhead to anything that does pointer arithmetic.
ryoskzypu has joined #osdev
<nikolar>
far pointers are segment+offset right
<mpetch>
Yes
Turn_Left has joined #osdev
<nikolar>
what are huge poimters then
ryoskzypu has quit [Remote host closed the connection]
Turn_Left has quit [Read error: Connection reset by peer]
<mpetch>
Huge pointers are still segment:offset but unlike far pointers that only support pointer arithmetic on the offset portion of the address - huge pointers can do pointer arithmetic on both the segment and offset.
<nikolar>
oh so they need to generate code for carry
<nikolar>
to the segment bit
<mpetch>
Exactly
<nikolar>
nice
joe9 has quit [Quit: leaving]
joe9 has joined #osdev
Lucretia has quit [Remote host closed the connection]
vykt has quit [Quit: Lost terminal]
m5zs7k has quit [Quit: m5zs7k]
gildasio has quit [Read error: Connection reset by peer]
gildasio has joined #osdev
m5zs7k has joined #osdev
bauen1 has quit [Ping timeout: 252 seconds]
bauen1 has joined #osdev
fedaykin has quit [Quit: leaving]
Velonie has quit [Ping timeout: 244 seconds]
fedaykin has joined #osdev
<kof673>
i'm not sure how the ia16 gcc + binutils is supposed to work, maybe i have an older version :D cannot open linker script file dos-com.ld cannot open linker script file dos-exe-small.ld
<kof673>
i can compile objects and make archives lol just no binaries/programs lol no headers or libc, i just pointed it at dev86 lol elks is elks i assume... anyways :D does not matter, just while that is the topic
edr has quit [Quit: Leaving]
sauce has quit [Ping timeout: 252 seconds]
sauce has joined #osdev
bauen1 has quit [Ping timeout: 268 seconds]
surabax has quit [Quit: Leaving]
cow321 has quit [Ping timeout: 252 seconds]
heat_ has quit [Read error: Connection reset by peer]
heat_ has joined #osdev
ring0_starr has quit [Ping timeout: 260 seconds]
bauen1 has joined #osdev
zijjgfs has joined #osdev
Arthuria has joined #osdev
heat_ has quit [Ping timeout: 248 seconds]
<the_oz>
How are you invoking it?
<the_oz>
think maybe could be there than in invoked
Velonie has joined #osdev
Velonie has quit [Ping timeout: 248 seconds]
bauen1 has quit [Ping timeout: 248 seconds]
zijjgfs is now known as ring0_starr
osmten has joined #osdev
bauen1 has joined #osdev
HumanG33k has quit [Ping timeout: 252 seconds]
Velonie has joined #osdev
HumanG33k has joined #osdev
HumanG33k has quit [Excess Flood]
HumanG33k has joined #osdev
Velonie has quit [Ping timeout: 252 seconds]
HumanG33k has quit [Ping timeout: 244 seconds]
HumanG33k has joined #osdev
Arthuria has quit [Ping timeout: 268 seconds]
HumanG33k has quit [Excess Flood]
HumanG33k has joined #osdev
bradd has quit [Remote host closed the connection]
bradd has joined #osdev
alexander has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
alexander has joined #osdev
bauen1 has quit [Ping timeout: 248 seconds]
bauen1 has joined #osdev
Rubikoid has quit [Ping timeout: 272 seconds]
goliath has joined #osdev
Rubikoid has joined #osdev
vasudevantv has joined #osdev
vasudevantv has left #osdev [#osdev]
GeDaMo has joined #osdev
bauen1 has quit [Ping timeout: 252 seconds]
netbsduser` has joined #osdev
heat_ has joined #osdev
Lucretia has joined #osdev
qubasa has joined #osdev
the_oz has quit [Read error: Connection reset by peer]
vdamewood has quit [Quit: Life beckons]
bauen1 has joined #osdev
kfv has joined #osdev
osmten has quit [Quit: Client closed]
hwpplayer1 has joined #osdev
TkTech has joined #osdev
hwpplayer1 has quit [Remote host closed the connection]
osmten has joined #osdev
kfv has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
osmten has quit [Quit: Client closed]
kilic has quit [Remote host closed the connection]
kfv has joined #osdev
kfv has quit [Remote host closed the connection]
kfv has joined #osdev
gorgonical has joined #osdev
kfv has quit [Remote host closed the connection]
kfv has joined #osdev
kfv has quit [Client Quit]
raphaelsc has joined #osdev
edr has joined #osdev
Left_Turn has joined #osdev
kfv has joined #osdev
kfv has quit [Client Quit]
alexander has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
<kof673>
README.md: make it mandatory to build elks-libc Jan 22, 2025 This is not very pretty, but it should reduce the number of possible ways to build the toolchain -- & the number of ways the build can go wrong.
raphaelsc has quit [Remote host closed the connection]
hwpplayer1 has joined #osdev
[Kalisto] has quit [Quit: Ping timeout (120 seconds)]
[Kalisto] has joined #osdev
cow321 has joined #osdev
<heat_>
kernel
<nikolar>
kornial
craigo has quit [Ping timeout: 248 seconds]
Velonie has joined #osdev
goliath has joined #osdev
Velonie has quit [Ping timeout: 248 seconds]
Velonie has joined #osdev
<zid>
colonel
<nikolar>
wrong
<zid>
liutenant?
<nikolar>
wrong again
<zid>
I give up
<nikolar>
good
<zid>
what was the answer
xenos1984 has quit [Read error: Connection reset by peer]
<nikolar>
krnl
<sbalmos>
just for that, I'm naming the idle thread in my kernel Sanders
<zid>
The apckage manager is 'bernie'
<heat_>
FEEL THE KERN
<zid>
I am once again coming to you with some package updates
<zid>
nikolar want to do some PEAR PROGRAMMING?
<nikolar>
PEARING?
<nikolar>
what are we PEARING
<zid>
I had a few ideas
<zid>
depends if you're game or not
<nikolar>
sure, why not
<sbalmos>
zid: probably would be better if you aliased sudo to bernie
<sbalmos>
I am once again asking for your superuser support!
xenos1984 has joined #osdev
gog has joined #osdev
xenos1984 has quit [Ping timeout: 252 seconds]
xenos1984 has joined #osdev
goliath has quit [Quit: SIGSEGV]
vykt has joined #osdev
hwpplayer1 has quit [Read error: Connection reset by peer]
surabax has joined #osdev
demindiro has joined #osdev
<demindiro>
gdb's Python API is pretty neat
<demindiro>
Being able to type printptr instead of x/8wx $rdi - 8 etc all the time made debugging a whole lot easier
<demindiro>
Also filtering backtrace to only include actual function pointers instead of literally everything on the stack
<demindiro>
btw, does UEFI use the fs and gs registers? Doesn't seem to be specified anywhere
<vykt>
demindiro: PINCE is basically a frontend for gdb's python api
<demindiro>
"The Windows ABI forbids modifying either of these segment registers.", so I guess the same applies to UEFI
<demindiro>
Though I guess I can just save and restore the registers before calling a UEFI function
<demindiro>
"All runtime interfaces are non-blocking interfaces and can be called with interrupts disabled if desired" so I can avoid worrying about any interrupts using the fs or gs registers too (while my code is running).
<heat_>
oh lord
<heat_>
here's a tip: don't assume too much from EFI and be as paranoid as possible
<heat_>
real UEFI doesn't match whatever they wrote down full of typos
heat_ is now known as heat
<demindiro>
Is it safe to disable interrupts? If I can at least guarantee that I suppose it should be fine to use whatever registers I want.
<demindiro>
As long as I restore them before calling out
<heat>
you should read linux efi source
<heat>
it's a bucket full of reality
<heat>
you'll notice something fun called "eh, we crashed mid efi runtime services? alright, never call this again and keep going"
<demindiro>
827: /* Disable interrupts around EFI calls: */
<demindiro>
So I should keep interrupts disabled at all times I guess
<demindiro>
which makes things easier actually
Turn_Left has joined #osdev
<nikolar>
heat: kek
the_oz has joined #osdev
Left_Turn has quit [Ping timeout: 244 seconds]
demindiro has quit [Quit: Client closed]
demindiro has joined #osdev
<zid>
demindiro: you know gdb has just normal C printf right?
<zid>
you don't x/8wx, you printf "%p"
<heat>
wdym, that won't do the same thing
<zid>
yea it does 1 not 8, but his message was the confusing one not mine honest gov
<demindiro>
zid: I'm not using C, I'm writing pure assembly for a "minimal" interpreter
<demindiro>
And I'm definitely not following any standard conventions for the interpreter itself
<heat>
printf "%p" won't deref
<zid>
I didn't say you were using C
<zid>
I said gdb has printf
<zid>
so you don't need a python api to print things
<zid>
or to use x/
<heat>
i've also noticed (informally) that doing *0xdeadbeef will deref 0xdeadbeef as an int*
<zid>
yea default is int, you can typecast
<heat>
not unsigned long
<zid>
try print (struct FILE *)0xDEADBEEF :P
<heat>
yes i do that
<heat>
i've been running into an issue now where to get the current process i need to get a per-cpu variable, and that's a PITA
<heat>
i will inevitably need to write some sort of gdb macro
<zid>
can you do funny things through the stub I wonder
<demindiro>
That's the kind of pretty printing I needed ^
<heat>
its hitting me pretty hard now because i've basically switched to using a clever pure function desguised as a macro (so you can Just Use it as a variable), so now i have no trace of a local variable assigned to the current process
<heat>
it's annoying
<zid>
yea that's cool
<demindiro>
And as heat said, that doesn't do the same thing
<zid>
yes
<zid>
but what you said was- nevermind
<demindiro>
I specifically need the contents as 32 bit integers
<zid>
going round in squirkles
<zid>
(so use %x then)
<zid>
(or %d or %u or %i)
<demindiro>
The contents of whatever is at the memory location
<kof673>
so basically, /* raw dogging it */ -- uefi code
xenos1984 has quit [Ping timeout: 245 seconds]
xenos1984 has joined #osdev
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 252 seconds]
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
td123 has quit [Ping timeout: 265 seconds]
elderK has joined #osdev
demindiro has quit [Quit: Client closed]
<vykt>
I'd suggest writing macros for every custom datatype. In the project I'm working on currently (not osdev) I have 100+ line macros to print large datastructures nicely. It's really worth learning, makes debugging so much faster.
<nikolar>
wouldn't it be better to write a function at that oiint
<nikolar>
point
blockhead has joined #osdev
<vykt>
Yeah maybe, I've not had a need to log it yet.
<heat>
a function?
<heat>
gdb on qemu can't call functions without choking itself out