I pushed my dirent syscalls
#OBOS (not vibecoded)
flint idol
ok time for execve
so it should be as simple as:
loading elf
pushing aux values
handing control over
if I understood properly, if the ELF is ET_DYN, then I load the dynamic loader it requests, and hand control over to the dynamic loader
so:
load dynamic loader
pushing aux values (includes telling it the executable via an FD I think?)
handing over control
reading execve's manual, practically all process state is ditched when calling execve
// NOTE(oberrow, 18:41 2024-09-11):
// I hate this.```lol
flint idol
reading execve's manual, practically all process state is ditched when calling e...
which includes all living threads
and blocked threads
so I guess I just send SIGKILL to each thread
thick jolt
```c
// NOTE(oberrow, 18:41 2024-09-11):
// I hate this.```
// NOTE(nyauxmaster, 17:28 2024-12-26):
// die
add this
flint idol
š«
thick jolt
š”
flint idol
@thick jolt
Core_MutexAcquire(&Core_GetCurrentThread()->signal_info->lock);
CoreH_AbortWaitingThreads(WAITABLE_OBJECT(Core_GetCurrentThread()->signal_info->lock));```your function is being used
in obos
nvm, read posix spec wrong
when I exec, are opened FDs preserved
Directory streams open in the calling process image shall be closed in the new process image.
but looking at man execve.2
that means DIR* stuff
white mulch
By default, file descriptors remain open across an execve(). File descriptors that are marked close-on-exec are closed;
white mulch
I found that in the man page but I assume its also detailed somewhere in the spec
yeah its detailed in here too https://pubs.opengroup.org/onlinepubs/007904875/functions/exec.html
File descriptors open in the calling process image shall remain open in the new process image, except for those whose close-on- exec flag FD_CLOEXEC is set. For those file descriptors that remain open, all attributes of the open file description remain unchanged. For any file descriptor that is closed for this reason, file locks are removed as a result of the close as described in close(). Locks that are not removed by closing of file descriptors remain unchanged.
thick jolt
flint idol
I read the spec wrong
flint idol
bru
I need to cancel io on exec
which like makes sense
but is like really boring
why is everything posix boring
flint idol
I'm working too slow
I gotta lock in
if I actually spend time programming instead of thinking I should have bash by the 28th (inaccurate prediction)
white mulch
maybe you are going to have bash before I do tho
flint idol
I gotta lock in
and I think the first step to locking in would be to killall discord
wait if I killall -9 discord would it still say I'm online
white mulch
no I don't think
vale nymph
flint idol
chat I got a new chair
I can finally osdev without feeling uncomfortable all the time
flint idol
maybe I am just hallucinating, but my brain is working faster on this chair
flint idol
I am nearly done execve
but this time I think I'm going to test it
it does way too much shit for it to go untested
static void write_vector_to_stack(char* const* vec, char** stck_buf, size_t cnt)
{
for (size_t i = 0; i < cnt; i++)
{
size_t str_len = strlen(vec[i]);
char* str = CoreS_ThreadAlloca(&Core_GetCurrentThread()->context, str_len+1, nullptr);
if (!str)
OBOS_Panic(OBOS_PANIC_FATAL_ERROR, "obos shat itself: your stack is not big enough to hold all these arguments");
memcpy_k_to_usr(str, vec[i], str_len);
stck_buf[i] = str;
}
}```hopefully that panic never gets hit
thick jolt
ā« 99 little bugs in the code ā«
ā« 99 little bugs ā«
ā« take one down, patch it around ā«
ā« 137 little bugs in the code ā«
flint idol
just pushed execve
and I will be testing it tomorrow
and I will also be testing some of the untested syscalls
as well as futexes
and after that I will implement stat
[[gnu::weak]] int sys_stat(fsfd_target fsfdt, int fd, const char *path, int flags,
struct stat *statbuf);```fsfdt
that looks like a key mash lol
[[gnu::weak]] int sys_stat(fsfd_target fsfdt, int fd, const char *path, int flags,
struct stat *statbuf);
[[gnu::weak]] int sys_statvfs(const char *path, struct statvfs *out);
[[gnu::weak]] int sys_fstatvfs(int fd, struct statvfs *out);```
So I guess I will be implementing those tomorrow after my testsI wonder what happens to my uacpi score if I use my old kernel's allocator
my third kernel booted a lot faster than this one
flint idol
it got faster
I think
nope
but it feels a lot faster
nvm
it's like the same speed
flint idol
I decided to try the fireworks test on current obos
and unfortunately it hangs because of an api change
with spinlocks
flint idol
but it does run for a bit, at least
thick jolt
thats cool
flint idol
cmake doesn't want to configure obos on my phone
even though I have clang
tell my toolchain to use clang
the toolchain file complains about no x86_64-elf-gcc cross compiler
and before that it says it saw clang
cmake is restarted
white mulch
did you pass the toolchain file properly with -DCMAKE_TOOLCHAIN_FILE?
flint idol
did you pass the toolchain file properly with -DCMAKE_TOOLCHAIN_FILE?
--toolchain=...
white mulch
ah, yeah I think that's basically the same
I were just thinking if you include()'d it then you can end up with weird stuff (I used to do that at some point)
flint idol
specifically it complains while "Detecting C compiler ABI info"
I've tried:
set(CMAKE_C_COMPILER_WORKS true)
set(CMAKE_CXX_COMPILER_WORKS true)```
which worked previously while using gcc, to no availwhat about set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
flint idol
good idea
it worked
*nearly worked
now my cmake files are complaining about the fact it's not on linux/windows
specifically because the hyper install binary is x86_64 only
cc @real pecan
white mulch
can't you compile it from source?
real pecan
cc <@353593948523986945>
TLDR?
flint idol
the hyper install binary has binaries for windows+linux x86_64
but not linux aarch64
which is kinda sad
because now I can't build obos on my phone
flint idol
the hyper install binary has binaries for windows+linux x86_64
but not linux aar...
and by linux aarch64 I mean android
real pecan
well u can build it yourself if u want
i dont have aarch64 linux to build one
i could cross compile but then still no way to test
flint idol
i could cross compile but then still no way to test
what does --arch do in build.py
real pecan
bootloader arch
flint idol
k
flint idol
and I will be testing it tomorrow
time to do this
I guess I might as well call the test program "init"
since it might as well become the init program eventually
real pecan
wait what are you working on exactly
flint idol
I'm testing a bunch of syscalls
real pecan
why do u want to compile it on your phone lol
thick jolt
why do u want to compile it on your phone lol
compile linux kernel on samsung galaxy s1
short mortar
Nyaux on Samsung Galaxy S1 when
flint idol
I just uncovered a dumb bug in my munmap function
in one place, it would set rng to nullptr
it would then use rng in the actual unmapping part of the function
why it even needed to use rng in the first place? idk.
flint idol
PSA: pwndbg is a nice gdb extension that makes gdb not so ass
I wonder if it'd be fine to call Mm_HandlePageFault to prefault a page
flint idol
Mm_HandlePageFault(user_context, fault_addr, PF_EC_RW|((uint32_t)info.prot.present<<PF_EC_PRESENT));
rather gdb is being stoobid
or clang is being stoobid
flint idol
`Mm_HandlePageFault(user_context, fault_addr, PF_EC_RW|((uint32_t)info.prot.pres...
because if I pass user_context to handle page fault
oh nvm
idk why I added that piece of code
flint idol
yeah it was a forgotten piece of code
thick jolt
squigglely line
flint idol
fr
flint idol
today I discover my huge page implementation seems to be completely broken
for normal cases
thick jolt
no i mean seriously
flint idol
yeah I saw
thick jolt
there was fucking one bug
flint idol
hey, at least it doesn't take a whole team of devs to fix one bug in obos
flint idol
this is driving me nuts
flint idol
today I will be:
- trying to get the profiling stuff to work
- rewriting my allocator
- finishing up the execve bug fixes
- hopefully not getting humiliated on the uacpi ops/s list
flint idol
*43.
44.
discord embed is fnuy and trimmed the corners for me so it looked like 3. 4.
but anyway, the VMA is slow as balls, as I expected
flint idol
I hate this
How The Actual Fuck Are You Executing NULL
How tf did going to user space work before but not now
it seems like I fucked up my vmm code (specifically Mm_MapViewOfUserMemory)
thick jolt
today I will be:
- trying to get the profiling stuff to work
- rewriting my allo...
u probs have a bug in ur allocator or smt
just like me
im sure u can get more in nyaux
flint idol
no, my allocator is dogshit
thick jolt
then*
thick jolt
no, my allocator is dogshit
nah my allocators are shit and even i got 1m ops
theres def js a bug
flint idol
as can be seen here
thick jolt
thats very slow
flint idol
indeed
seems like my cpu has schizophrenia
it write-faults on a writeable, present page
flint idol
this shit is driving me crazy
why tf is it trying to execute the stack
ok
I got further
I fixed it
flint idol
it write-faults on a writeable, present page
it turned out the reason for that was because I was setting the supervisor bit on the user page when I faulted it in
time to rewrite my allocator
for the funnies, I should write it in obos userspace
I mean, what could possibly go wrong
flint idol
fuck this shit
flint idol
I uncovered a bug
I wasn't setting rsp0 to the per-thread kernel stack before going to usermode
but doing that causes a double fault
flint idol
I wasn't setting `rsp0` to the per-thread kernel stack before going to usermode
nvm, that is a bug, given my page table setup
flint idol
obos and nyaux have switched places or smth
so I know exactly what my bug is
but I have no idea how to fix it
breif: stack corruption due to the per-cpu temp stack being used for just about everything scheduler-related
flint idol
just use per thread stack
kpti
makes it so I need to map it in two places
the kernel's cr3
and the user's cr3
and it might be hard to keep track of both allocations
but that is probably the solution I end up going with
weak kestrel
https://tenor.com/view/it-seems-the-tables-have-turned-liamdxtd-gif-24274216
turns have tabled
flint idol
fr
I might try and make a function like obos_status Mm_QuickVMAllocate(size_t sz) for the kernel as a quicker alternative to Mm_VirtualMemoryAlloc
flint idol
which, as can be seen here, isn't very fast
weak kestrel
I might try and make a function like `obos_status Mm_QuickVMAllocate(size_t sz)`...
why not make the current one quicker
flint idol
I will also be doing htat
*that
but it still takes a lot of arguments
which are like a pain to type out
weak kestrel
no default parameters?
flint idol
C
weak kestrel
weak kestrel
you mean stl? 
flint idol
std::cout << "my ass"
weak kestrel
std::println("no mine");
flint idol
Instead of debugging this bug, I am taking a walk
Maybe I find the bug that wag
*way
flint idol
I'm back now with a clear mind
wait
I think I got it to work
SIGILL
I'm hoping that has something to do with SSE not being enabled yet
nope
it's .byte 0x1f
the instruction there should be add rsp, 0x20
white mulch
what are you trying to do?
flint idol
what are you trying to do?
not crash
I have figured out that the mmap syscall is corrupting part of .text
but I did test the mmap syscall in user space before, so this is weird
flint idol
it's `.byte 0x1f`
and I have figured out the reason for that
the arguments passed to the function are funky
the first three (passed through rdi,rsi,rdx) are fine
the next two (passed through r8,r9) are not
as in, corrupted
and also made it so that the 5th argument of that function happened to be the return address from the syscall
the 4th argument was a pointer to something
the 5th argument is status
this code ran
fixed it
it was a bug with how I passed arguments to syscalls in my userspace shim
let's go
I'm in userspace
with C
*C without a libc
oh wait that's basically the same thing as C
flint idol
the allocator is going pretty well
allocation seems to work fine
freeing seems to work fine
my only concern is realloc
which idk how to implement
that's the actual code
help would be much appreciated
for how to implement realloc
typedef struct freelist_node {
struct freelist_node *next, *prev;
} freelist_node;
_Static_assert(sizeof(freelist_node) <= 16, "Internal bug, report this.");
typedef struct freelist {
freelist_node *head, *tail;
size_t nNodes;
} freelist;
enum {
REGION_MAGIC = 0xb49ad907c56c8
};
typedef struct region {
void* start;
size_t sz;
uint64_t magic;
struct region *next, *prev;
} region;
typedef struct cache {
freelist free;
struct {
region *head, *tail;
size_t nNodes;
} region_list;
} cache;```if I didn't need sized frees, I would've done it by doing:
void* new = alloc(newsz);
memcpy(new, old, oldsz);
free(old);```why not make realloc take in the old size?
flint idol
well that would work
but uacpi doesn't give me the old size
so I'd need to have something hacky there
or ask infy kindly
to pass the old size to realloc if UACPI_SIZED_FREES
white mulch
I think it would make sense with that option
flint idol
wait did infy even add uacpi_kernel_realloc??
white mulch
no
flint idol
I coulda sworn he did
real pecan
i was going to
but then i changed logic in the only place that could need it
and now its not needed
thick jolt
@flint idol if ur having any bugs rn
i have JUST the thing to solve it
__asm__ volatile ("ud2");
add these everywhere in ur kernel
it will solve everything
empty kernel
that is essentially the same as a while (1);, except you get an exception instead of it freezing
thick jolt
good to hear!
flint idol
after doing the most basic allocator tests
I will be integrating this in the kernel
well I tested it in userspace anyway
just in case
flint idol
well I tested it in userspace anyway
with basic tests
static void test_allocator()
{
void* to_free = NULL;
size_t free_size = 0;
while (true)
{
size_t sz = random_number() % 4096 + 256;
char* ret = malloc(sz);
ret[0] = random_number8();
ret[sz-1] = random_number8();
if (random_number() % 2)
{
free(to_free, free_size);
to_free = ret;
free_size = sz;
}
}
}```it SEGVs almost immediately
thick jolt
well I tested it in userspace anyway
nice u have userspace
lean glen
Pointer arithmetic overflow?
flint idol
I figured it out
fuck this shit
I've been debugging the elf loader
for the past 3 fucking hours
all I did was add a fucking global variable to the init program
and it falls in shambles
I will continue debugging tomorrow
this is driving me crazy
empty kernel
no one is online no one can test nyaux ec
I can if you promise it won't brick my laptop
thick jolt
I can if you promise it won't brick my laptop
its fine\
qookie is testing
and
we have an issue where we are stuck installing an address space handler
flint idol
fixed the bug I think
I've had the test running for a couple seconds, it's already allocated around ~69M of virtual memory
and is currently at 21948 allocations
and this is in tcg
in userspace
although, when I change it to allocations < page size, it segfaults
but it's a GPF, not a PF
on a non-canonical address
flint idol
I fixed it
flint idol
might be this one's fault
?
inland radish
you might be seeing bad thread IDs for that reason
flint idol
well good thing I'm not seeing bad TIDs
that message is a week old btw
anyway I'm going to run this userspace allocator test until it OOMs
which hopefully shouldn't crash
and instead the memory manager starts doing stuff like checking standby
for free memory
flint idol
np
many memory used
what the hell
it went down?
it triple faulted lmao
triple faults on OOM ā
interesting
the dirty page list and standby page list are both empty
which means pages are never being put on dirty/standby
when they probably should be
I set the working-set capacity of the new process' context (I forgor)
and now I discover a bug with swap
specifically dirty/standby pages
it seems like a ws-entry contains ancient page info, which gets passed to Mm_SwapOut, causing it to put the wrong physical page on the standby list (but since this page is still paged in many other places, it's not actually put on the list yet)
flint idol
fixed that
except there's another bug
basically, an allocation of 5 pages is made through the PMM
then we're out of memory in the free list, so we try to take from standby
this won't work since we only have 1-page regions on standby, but we need 5-pages
and since we have no huge pages on standby, we can't take from there either
the only solution to this: don't make allocations with the PMM that are not one-paged, or huge-paged
short mortar
Or allow PMM to return non-contiguous pages?
short mortar
Or allow PMM to return non-contiguous pages?
My PMM can do that 
flint idol
I have a special allocator in the kernel, Mm_Allocator, which is responsible for allocating stuff for the VMM, as otherwise there is a circular dependency. This allocator uses the PMM+HHDM directly
short mortar
But that can just request 1 page at a time
flint idol
the only solution to this: don't make allocations with the PMM that are not one-...
maybe a bit implied from this
short mortar
I think my solution to everything would be to fail when pages can't be allocated
flint idol
no OOM handling
flint idol
no OOM handling
flint idol
And catch that, free memory, and repeat
probably a bad solution
at least, it's a bad solution as the first resort
for OOMs
short mortar
It should be very easy to do though
And would save me from thinking about deadlocks and whatnot
flint idol
#1141057599584878645 message
short mortar
Random tripple faults
flint idol
since you're planning on using the WS for swap and whatnot, read those messages
short mortar
Yeah I saw that
flint idol
yeah, that's for OOM handling
and when the free list runs out, you yoink a standby page
short mortar
He's talking about blocking the kernel thread
My kernel can't do that
So basically this unconditionally
flint idol
"blocking for free pages" probably just means waiting until standby_list.nNodes != 0
but it could mean something else
flint idol
then I guess microkernel skill issue
short mortar
one stack per CPU skill issue
I can do something which would allocate more stacks dynamically as needed
But that would be a huge headache
Like you block when there's no memory
Yet somehow you have to allocate stacks
real pecan
unfortunately, fixing this bug causes the uacpi ops/s count to drop
What do u get atm
flint idol
doing that doubled my ops/s
and changing to an optimized build also improved the score
flint idol
I'm going to optimize page mapping
not mmap
but the actual PTE manipulation code
first I will start by adding an optional parameter to MmS_SetPageMapping which contains info on the last PTE accessed while mapping
// mm/context.h
typedef struct arch_pte_info arch_pte_info;
// arch/x86_64/map.h
struct arch_pte_info {
uintptr_t* tables[4];
uint8_t last_idx;
};```that way I won't have to walk PTEs on each call to MmS_SetPageMapping when I'm simply mapping contiguous virtual memory
-OBOS_EXPORT obos_status MmS_SetPageMapping(page_table pt, const page_info* page, uintptr_t phys, bool free_pte);
+OBOS_EXPORT obos_status MmS_SetPageMapping(page_table pt, const page_info* page, uintptr_t phys, bool free_pte, arch_pte_info* cached_pte_info);```
torpid wigeon
i have an idea
flint idol
yes
torpid wigeon
typedef struct {
void* data;
uint8_t padding[4088];
} page;
elaborate
flint idol
nyaux I'm coming for your score
flint idol
once I get lazy IRQL and these optimizations
flint idol
<:chad:815144781842743334>
what even is your score?
flint idol
without ubsan
with or without optimizations?
thick jolt
I'll be back in 1 hour and 12 minutes
i am having my nyuax curse
flint idol
I will test it, then I will merge it
thick jolt
kk
flint idol
inb4 the 2 changes cause a triple fault
thick jolt
lol
flint idol
@thick jolt merged
thick jolt
<@787341689333350450> merged
thanks
flint idol
For future reference: rdmsr is pretty slow, avoid using it if you can
flint idol
Tomorrow, I will start TTYs
I have been procrastinating those for some 4-5 months by now
well not tomorrow
today
flint idol
ngl ttys sound pretty boring
I just want to port mlibc
but I should refrain, since I need TTYs for bash
I think
weary hound
just implement ptys and offload terminals to userspace :^)
(not that it's a massive difference)
flint idol
afaik the only difference is how the raw input/output is actually collected if that makes sense
weary hound
yeah ptys vs serial vs ttys only differ on what happens on the master side
flint idol
I just want to port mlibc
might as well, tbh
sys_isatty will always return 0, I'm sure that's fine for now
weary hound
ptys have another process handle it, for serial it's handled by a terminal on the other side of the the serial line, for ttys the kernel manages the framebuffer console and keyboard input
weary hound
sys_isatty will always return 0, I'm sure that's fine for now
you want to return ENOTTY if you want to pretend there are no ttys
weary hound
bash will think it's not running in interactive mode
weary hound
yeah
vale nymph
ttys arent that bad
flint idol
ttys arent that bad
yes but they're boring
vale nymph
you just have to bang your head against the wall for a few days
weary hound
well then it will behave like an interactive bash
flint idol
hm
vale nymph
you dont really need a lot of the tty stuff for bash to be happy
weary hound
yeah bash runs in raw mode anyway
since it uses readline for line editing
flint idol
anyway, time to make a gcc target
for x86_64-obos
I got m68k-obos
so it theoeretically shouldn't be much work
main girder
My kernel can't do that
how come
flint idol
probably some sort of microkernel thing
short mortar
It's nonpreemptive
main girder
It's nonpreemptive
that doesnt have anything to do with whether you can block
short mortar
It's nonpreemptive
Like idk if it's the right term
But I don't switch kernel stacks on blocking
main girder
why
short mortar
But abandon the operaton and start doing different things in the same context
Until it can be continued
real pecan
like an event loop?
short mortar
I guess so
main girder
But abandon the operaton and start doing different things in the same context
this sounds like how a scheduler works except bad-ified
bc fewer capabilities
(cant block)
main girder
u havent like justified why thats better
short mortar
Like I just change the current_thread pointer
short mortar
u havent like justified why thats better
It saves memory on kernel stacks
supposedly at least I guess
main girder
there are much less restrictive ways to do that
u can outswap kernel stacks for threads that have been asleep a long time for instance
and when you do this you can like just straight up free up all the pages for the kernel stack that are beneath the current stack pointer
and swap them back in / re-allocate them before allowing the thread to execute again
windows does this and i think macos also does (mach definitely used to, i havent checked if xnu retains this ability in the modern day)
short mortar
Idk I wanted to do something different
It kinda works so far
I have smp and multithreading and blocking syscalls what else do I need
empty kernel
where does it fail
flint idol
nvm
flint idol
nvm it does
make: *** [Makefile:1027: all] Error 2```but I don't see an error message
empty kernel
I remember spending an entire day trying to get an os specific toolchain
empty kernel
but I don't see an error message
scroll up a bit
flint idol
I remember spending an entire day trying to get an os specific toolchain
that's teh day I started counting
in the cherno server
empty kernel
yep
empty kernel
scroll up a bit
sometimes it will be up a bit
flint idol
scroll up a bit
I'm doing make
so the error message is closer
so wait a bit
/home/serveradmin/m68k-gcc/binutils/ld/configure: line 19284: ../../binutils/ld/emulparams/elf_x86_64_myos.sh: No such file or directory```oops
empty kernel
I assume you are following this: https://osdev.wiki/wiki/OS_Specific_Toolchain (or the osdev.org one)
flint idol
yeah
I forgot to change the naem of the script
I actually never made that
so ig I can remove that
and change it to
empty kernel
haven't you made an os specific toolchain before?
flint idol
I have
flint idol
about a year ago
thick jolt
yess!!!!!!!!
flint idol
!!!
flint idol
I will test it
empty kernel
have you made some EC improvements?
thick jolt
have you made some EC improvements?
no i have no idea why ec is dying
flint idol
configure: error: *** A compiler with support for C++17 language features is required.
bruh
I don't have a compiler lol
fixed that
empty kernel
no i have no idea why ec is dying
I'll test this version on my laptop anyway. the PCI stuff might have changed something
flint idol
attached is the last thing I see
empty kernel
binutils is the easy part. GCC is a pain
flint idol
I was able to get it to work on the m68k
aka m68k-obos-gcc
so surely this should be the same since I had very minimal changes
(m68k gcc is even more of a pain to get working properly with relocations)
waiting for gcc to compile is like watching paint dry
empty kernel
yep
thick jolt
@flint idol can u try this pls
flint idol
sure
thick jolt
thanksss
flint idol
still hangs @thick jolt
flint idol
d-man
flint idol
https://tenor.com/view/dhar-mann-so-you-see-gif-23268701
you have been sentenced to building gcc
on a pentium 4
thick jolt
flint idol
and watching it the entire time
uhh I think I accidentally built gcc with lto
which doesn't sound very good for the linker's memory usage
/home/serveradmin/opt/cross/x86_64-obos/bin/ld: cannot find -lc: No such file or directory```
@empty kernel do you have any idea why I could've gotten this
this is during libgcc build
flint idol
yea
empty kernel
You don't have a c library, but libgcc wants one
I don't remember how I avoided that
what does your gcc/config/obos.h look like?
flint idol
/* Useful if you wish to make target-specific GCC changes. */
#undef TARGET_MYOS
#define TARGET_MYOS 1
#undef LIB_SPEC
//#define LIB_SPEC "-lc" /* link against C standard library */
#define LIB_SPEC ""
/* Files that are linked before user code.
The %s tells GCC to look for these files in the library directory. */
#undef STARTFILE_SPEC
#define STARTFILE_SPEC "crt0.o%s crti.o%s crtbegin.o%s"
/* Files that are linked after user code. */
#undef ENDFILE_SPEC
#define ENDFILE_SPEC "crtend.o%s crtn.o%s"
/* Additional predefined macros. */
#undef TARGET_OS_CPP_BUILTINS
#define TARGET_OS_CPP_BUILTINS() \
do { \
builtin_define ("__obos__"); \
builtin_define ("__unix__"); \
builtin_assert ("system=obos"); \
builtin_assert ("system=unix"); \
builtin_assert ("system=posix"); \
builtin_define ("__SVR4_ABI__"); \
} while (0);
#define PID_TYPE uint64_t
#undef LINK_SPEC
#define LINK_SPEC "%{shared:-shared} %{static:-static} %{!shared: %{!static: %{rdynamic:-export-dynamic}}}"
@empty kernel
flint idol
except for the CONFIG_MYOS
empty kernel
oh yeah
flint idol
but `-lc` should be in your LIB spec
but I don't have a libc yet
empty kernel
if you are following the guide, then it doesn't matter
torpid wigeon
but I don't have a libc yet
mlibcv
empty kernel
and don't forget that you need the libc headers for libgcc to build
empty kernel
this is what I did for mine: https://github.com/FrostyOS-dev/gcc/commit/4207fa490f7fff71f121f4e7cf6305737fa92215 (ignore libstdc++-v3/configure)
flint idol
solved it
but libgcc fails at link time
so I guess the solution is to:
- yoink a libgcc from elsewhere
- compile mlibc for obos
- use those crt0.o and libc files
- rebuild binutils+gcc+libgcc once again with the new sysroot
at least I think this is the right approach?
empty kernel
that shouldn't be the solution
flint idol
empty kernel
are you trying to build libgcc as a dynamic lib or static lib?
flint idol
considering I never paid attention to that, I think it's whatever the default is
and here it's making an .so
empty kernel
that could be an issue
you might need to force it to make a static lib
then later you can go back and compile it dynamically
flint idol
what if I just use the thing for x86_64-elf
I am trying that rn
exact same thing
I'm going to try one last thing
which is adding:
#undef LINK_SPEC
#define LINK_SPEC "%{shared:-shared} %{static:-static} %{!shared: %{!static: %{rdynamic:-export-dynamic}}} -z max-page-size=4096"```
to gcc/config/obos.hwhat does your kernel do with EC events?
after the stuff in #1230349543623757845, I'm wondering if your kernel produces events on my laptop
flint idol
after the stuff in <#1230349543623757845>, I'm wondering if your kernel produces...
I can send you an iso In a few hours
As I am going to sleep right now
empty kernel
alright
thick jolt
iso
thick jolt
any events tho?
flint idol
I can provide you with an iso with debug logs and whatnot when I wake up
empty kernel
alright
short mortar
so I guess the solution is to:
- yoink a libgcc from elsewhere
- compile mlibc f...
You shouldn't need libgcc for libc
Like you're just supposed to compile the compiler, then libc, then the rest of libraries
At least that's what I was doing
sharp pike
You shouldn't need libgcc for libc
but you do
short mortar
why
short mortar
but you do
Maybe if you compile dynamic library
sharp pike
on x86-64, for example, because complex (math) functions are part of the standard library, and those require libgcc support code
on other architecture, like IA-32, you may well need libgcc for anything needing 64-bit math for example, etc, etc
flint idol
through some trickery of the compiler (inhibit_libc=true), I was able to get an obos compiler
with libgcc
compile mlibc with it
then compile a "Hello, world!" program
then for the dynamic linker to fail to load in obos
flint idol
I am able to get the dynamic linker to load
but it SIGILLs
oh, it also randomly triple faults
I wonder why..
well the SIGILL is because of SIMD
flint idol
oh, it also randomly triple faults
I will fix this
then enable SIMD stuffs
I seem to also get GPFs
on iretq
in the ISR handler code
wtf
this is the stack at the time of fault
this appears to be returning to user mode
and if that is truly the case, then the bug is that I'm switching to a temporary cpu stack when I shouldn't be
fixed it
it was in the default signal handler
diff --git a/src/oboskrnl/arch/x86_64/ssignal.c b/src/oboskrnl/arch/x86_64/ssignal.c
index 552c9e3..7bbafbd 100644
--- a/src/oboskrnl/arch/x86_64/ssignal.c
+++ b/src/oboskrnl/arch/x86_64/ssignal.c
@@ -101,7 +101,7 @@ void OBOSS_RunSignalImpl(int sigval, interrupt_frame* frame)
frame->ss = 0x10;
frame->ds = 0x10;
frame->cr3 = MmS_GetCurrentPageTable();
- frame->rsp = (uintptr_t)CoreS_GetCPULocalPtr()->arch_specific.ist_stack + 0x20000;
+ frame->rsp = (uintptr_t)Core_GetCurrentThread()->kernelStack + 0x10000;
return;
}
if (sig->flags & SA_SIGINFO)
time for SIMD shenanigans
flint idol
well this is the last thing I see before the segfault
the offending entry is PLTRELSZ
short mortar
My proposed solution: use pmOS libC
(it implements signals in userspace)
thick jolt
hi
flint idol
it crashes
thick jolt
hi
flint idol
hai
thick jolt
hai
white mulch
hi
thick jolt
hey
flint idol
it panics on the ensure line
white mulch
do you push the null entry first?
thick jolt
@flint idol join voice 0
flint idol
no
thick jolt
flint idol
it seems like it expects to be at the environment pointers
but I don't have any passed to /init
i.e., envp[0] = nullptr
nvm I read that code wrong
it was alignment stuff
vale nymph
but I don't have any passed to `/init`
btw, by convention usually argv[0] is a pointer to the command
flint idol
my argv[0] is a pointer to a string literal "/init\0"
vale nymph
nice
flint idol
soo nothing wrong there
after fixing that alignment problem
now I want to add syscall logging
flint idol
this is the last thing it sees before panicking
which I assume is because the base address of the executable I'm trying to run is non-zero
now that I'm debugging C++ code, I get reminded of why I hate debugging C++ code
flint idol
implicit constructor calls when you pass arguments to functions
step
ah first let me take you to the constructor of that one argument
anyway, I need to implement sys_open and related file sysdeps
thick jolt
less gooo
flint idol
which means bash will be coming to an obos near you
thick jolt
flint idol
soonā¢ļø
torpid wigeon
it's like the upstream code is broken
white mulch
bash code is disgusting tbh
torpid wigeon
i ported bash before
you don't even have user space
white mulch
it even has k&r garbage
flint idol
you don't even have user space
he had bash
thick jolt
you don't even have user space
no my first nyaux rewrite
timid elk
which means bash will be coming to an obos near you
YAY
flint idol
many moons ago
torpid wigeon
bruh
white mulch
I should also try getting bash
flint idol
it still is /hj
timid elk
9 moons and 3 weeks ago
real pecan
it still is /hj
WTH does hj stand for
flint idol
half joking
timid elk
half joke
white mulch
half joke
torpid wigeon
half joking
timid elk
worst tone tag ever
real pecan
Ah
timid elk
never use /hj
thick jolt
nah but seriously
the first nyaux was actually
the worst kernel
u can look at it
it was
so awful
if u think my code is awful now?
check old nyaux
thick jolt
ill even give u the archived kernel repo
timid elk
tbh i should create a linux distro to test nixstrap with
thick jolt
timid elk
tbh i should create a linux distro to test nixstrap with
and i can use mlibc because why not
timid elk
you ARE the build orchestrator
flint idol
when you word it like that
timid elk
when i word it like that š³š³
timid elk
why haram
thick jolt
haven't you fucked nyaux before
š
timid elk
haven't you fucked nyaux before
i don't think one can fuck an OS
thick jolt
nixstrap version 2 when
timid elk
never
flint idol
time to make obos-strap
timid elk
it is on version 0 now
flint idol
because why not
timid elk
NOO
use nixstrap
anyhow
good night
good night to all nixstrap fans
sweet dreams nyauxmaster
white mulch
time to make `obos-strap`
use qpkg 
timid elk
ban
white mulch
I used toml
[general]
name = "system-cc"
version = "20.0.0-e59582b"
src = [
"https://github.com/Qwinci/crescent-bootstrap/raw/refs/heads/binary-system-cc/system-cc-@[email protected]",
"https://github.com/Qwinci/crescent-bootstrap/raw/refs/heads/binary-system-cc/system-cc-@[email protected]",
"https://github.com/Qwinci/crescent-bootstrap/raw/refs/heads/binary-system-cc/system-cc-@[email protected]",
"https://github.com/Qwinci/crescent-bootstrap/raw/refs/heads/binary-system-cc/system-cc-@[email protected]",
"https://github.com/Qwinci/crescent-bootstrap/raw/refs/heads/binary-system-cc/system-cc-@[email protected]",
"https://github.com/Qwinci/crescent-bootstrap/raw/refs/heads/binary-system-cc/system-cc-@[email protected]"
]
depends = ["hzlibc"]
workdir = "system-cc"
[prepare]
args = [
["cat", "@BUILDROOT@/archives/system-cc-@[email protected].*", ">", "system-cc-@[email protected]"],
["tar", "--strip-components=1", "-xf", "system-cc-@[email protected]"]
]
[install]
args = [
["mkdir", "-p", "@DESTDIR@"],
["tar", "-C", "@DESTDIR@", "--strip-components=1", "-xf", "@SRCDIR@/system-cc-@[email protected]"]
]
{
"name": "mlibc",
"description": "A portable C library",
"git-commit": "idk some git commit"
"url": "https://github.com/OBOS-dev/mlibc",
"depends": [ "x86_64-obos-gcc-bootstrap" ],
"patches": [ "path/to/patch.am", "path/to/patch2.am" ],
}```I guess that's going to be the general format
flint idol
(I'd rather die than use XML)
flint idol
was that xbstrap?
white mulch
yes
torpid wigeon
I used toml
based
i did too
[package]
name = "host-gcc"
version = "latest"
archs = ["x86_64"]
host = true
[[sources]]
repo = "https://gcc.gnu.org/git/gcc.git"
branch = "master"
patches = ["menix.patch"]
[dependencies]
host = ["automake", "autoconf", "gcc", "ld", "as", "pkg-config"]
build = ["host-binutils", "mlibc-headers"]
[configure]
script = """
${SOURCE_DIR}/configure \
--target=${OS_TRIPLET} \
--enable-languages=c,c++,lto \
--with-sysroot="${SYSROOT_DIR}" \
--prefix="${PREFIX_HOST}" \
--enable-threads=posix \
--disable-multilib \
--enable-initfini-array \
--disable-shared \
--disable-nls
"""
[build]
script = """
make -j${THREADS} inhibit_libc=true all-gcc
make -j${THREADS} inhibit_libc=true all-target-libgcc
"""
[install]
script = """
make install-gcc
make install-target-libgcc
"""
wait toml has multiline strings that could be better lol
torpid wigeon
yea
my thing is shell based, so i don't have that argv stuff
these strings just get concatenated with a common.sh script and then ran
though i'm doing containerized and distributed builds soon
white mulch
I also just concatenate the args separated with spaces and pass the whole thing to sh -c
torpid wigeon
what's the point of the args array then
white mulch
to have different cmds on different lines
and they are also run in their own sh instance
torpid wigeon
like makefiles?
white mulch
like makefiles?
yes ig
flint idol
how does gnu over engineer a "Hello, world!" program
real pecan
10 billion locale related things?
flint idol
{
"name": "hello",
"description": "GNU Hello",
"url": "https://git.savannah.gnu.org/git/hello.git",
"git-commit": "274bd5b954066558a5ead00d3cceefe21ecdba9b",
"depends": [],
"patches": [],
"bootstrap-commands": [
[ "./bootstrap" ],
[ "./configure" ],
],
"build-commands": [
[ "make" ]
]
}
anyway, I've made a test recipe
for obos-strap
real pecan
Bash soon?
flint idol
yes
I originally wanted it by the end of this year
but alas, I was too tempted to make this
real pecan
This?
flint idol
obos-strap
real pecan
Yet another package thing
flint idol
Yes.
vale nymph
I got into a prompt with these
extern syscall_mmap
extern syscall_openat
extern syscall_read
extern syscall_seek
extern syscall_close
extern syscall_archctl
extern syscall_write```
print is mlibc logging and archctl is tlb stuffnot tlb
tls
flint idol
wait that's it
flint idol
so I can already do that
bah why doesn't bash have a git repo
or if it does why can't I find it
vale nymph
flint idol
thanks
white mulch
or https://github.com/bminor/bash in case the gnu one is slow like they sometimes are
vale nymph
should probably just download it from a gnu mirror or something
flint idol
cloning bash rn
real pecan
cloning bash rn
Write from scratch
flint idol
I already cloned it
I used --single-branch
so it took like 20 seconds
@vale nymph so uhh how do I configure it to build on obos
./configure --host=x86_64-obos
is what I tried
vale nymph
./configure --host=x86_64-obos --prefix=prefix
flint idol
checking build system type... x86_64-pc-linux-gnu
checking host system type... Invalid configuration `x86_64-obos': OS `obos' not recognized
configure: error: /bin/bash ././support/config.sub x86_64-obos failed```you have to add yourself to config.sub
flint idol
ok
vale nymph
./configure --host=x86_64-obos --prefix=prefix
I use ./configure --host=x86_64-astral --prefix=${prefix} --without-bash-malloc
vale nymph
or you can do the funny autoreconf stuff that copies a config.sub automatically
flint idol
bah
externs.h:204:13: error: conflicting types for 'dprintf'; have 'void(int, const char *, ...)'
204 | extern void dprintf PARAMS((int, const char *, ...)) __attribute__((__format__ (printf, 2, 3)));
| ^~~~~~~
In file included from /home/serveradmin/mlibc-obos/usr/include/stdio.h:227,
from alias.c:33:
/home/serveradmin/mlibc-obos/usr/include/bits/posix/posix_stdio.h:33:47: note: previous declaration of 'dprintf' with type 'int(int, const char *, ...)'
33 | __attribute__((format(__printf__, 2, 3))) int dprintf(int __fd, const char *__format, ...);
what have I done š
vale nymph
wtf
flint idol
ok I reinstalled my headers
In file included from copy_cmd.c:25:
bashtypes.h:28:10: fatal error: sys/types.h: No such file or directory
28 | #include <sys/types.h>
| ^~~~~~~~~~~~~
compilation terminated.
In file included from hashcmd.c:24:
bashtypes.h:28:10: fatal error: sys/types.h: No such file or directory
28 | #include <sys/types.h>
| ^~~~~~~~~~~~~
compilation terminated.
flags.c:24:12: fatal error: unistd.h: No such file or directory
24 | # include <unistd.h>
| ^~~~~~~~~~
compilation terminated.
make: *** [Makefile:105: copy_cmd.o] Error 1
make: *** Waiting for unfinished jobs....
In file included from dispose_cmd.c:23:
bashtypes.h:28:10: fatal error: sys/types.h: No such file or directory
28 | #include <sys/types.h>
why is mlibc not giving me these
vale nymph
did you put them in your sysroot in the include dir
flint idol
I just meson installed into my sysroot
weary hound
for bash you probably want the version archive and not the repo
flint idol
```
In file included from copy_cmd.c:25:
bashtypes.h:28:10: fatal error: sys/typ...
as for these errors?
weary hound
show ls path/to/my/system/root/usr/include
flint idol
weary hound
also confirm that gcc is using it as a sysroot (x86_64-obos-gcc -v shows the configure args, incl. --with-sysroot=...)
weary hound
did you by any chance only compile the ansi option
flint idol
also confirm that gcc is using it as a sysroot (`x86_64-obos-gcc -v` shows the c...
sysroot is being used
flint idol
did you by any chance only compile the ansi option
yes
weary hound
for bash you also need the posix option
flint idol
ok
vale nymph
yeah
flint idol
weary hound
ansi is not enough to make a shell