thats one of the ld.so load addresses
#Nyaux
tawdry mirage
this is the address mlibc just mmaped
kind root
Because you fucked it up
elder shoal
do info mem
surreal path
tawdry mirage
its mapped?
missing 2 zeroes?
elder shoal
no write?
surreal path
oh im stupid
kind root
Bro mapped it read-only
kind root
Mlibc pronouns is he him confirmed
surreal path
i have syscalls
cinder plinth
yeah
surreal path
lol
surreal path
<@787341689333350450> do you have stdin/stdout/stderr
no
kind root
Lol
elder shoal
you'll need that
kind root
I removed it
cinder plinth
just do if fd < 3
kind root
If fd ❤️
kind root
Speedrun dead
kind root
Thats an unsigned number tho
cinder plinth
.so.8 is a symlink
kind root
Bro is fucked
kind root
Just read linked file and follow it
kind root
Its just a path
tawdry mirage
the symlink just contains the path to the actual file
surreal path
in ascii?
kind root
No, in utf-256
tawdry mirage
holy
cinder plinth
nah
kind root
Lmao
kind root
Octal encoded endiannes
elder shoal
at least make it page aligned smh they should make it utf-${pagesize_of_the_system} because portability is for cowards
tawdry mirage
if a vnode is a symlink
symlinks have their own file type
kind root
how do i know if its a symlink
Its just one other file type
tawdry mirage
it is a symlink
a hard link is indistinguishable from a regular file (because every regular file is already a hard link)
kind root
This is just ls showing you the resolved path I think
tawdry mirage
yeah
surreal path
okay this check is failing
tf???
oh wait
tried reading the data out of a symlink
clearly thats not
proper
do symlinks have file size
in tar
wicked loom
it's a symlink
wicked loom
it may not be i think
surreal path
the size of the file is zero
wicked loom
the US government or somethin
surreal path
ustar my butt
wicked loom
that's why it's called UStar
surreal path
star into the butt
wicked loom
no i think it's 0 terminated lol
tawdry mirage
that's why it's called UStar
uhm akshually it's unix standard tar
surreal path
no i think it's 0 terminated lol
bru
wicked loom
uhm akshually it's unix standard tar
you see i spread 2 misinformation
that's 2 rubles deposited to my bank account
tawdry mirage
ah i see
surreal path
right forgot null terminator
strlen + 1
BRO
hZ
bRO
can u be normal for once and write normally to my file
THERE WE GO
THERE WE FUCKIN GO
will symlinks be absolute paths?
like all the time?
i suppose they would be?
tawdry mirage
symlinks can be relative
in which case they're relative to where the symlink is
it might be a bit problematic with how you created the tar archive but ig you could just prepend a / to the symlink path
wicked loom
will symlinks be absolute paths?
no
all symlinks are relative
to the location of the symlink
surreal path
oka
tawdry mirage
all symlinks are relative
oh huh my bad
Symbolic links are interpreted at run time as if the contents of the link had been substituted into the path being followed to find a file or directory.
from man 2 symlink
istr symlinks with an abs path but i can't find any examples on my system :^)
unkempt relic
istr symlinks with an abs path but i can't find any examples on my system :^)
you know what, i had expected that too
tawdry mirage
hm no i do have absolute symlinks on my system
wicked loom
istr symlinks with an abs path but i can't find any examples on my system :^)
well yeah if a path starts with a /...
tawdry mirage
yeah but the wording implies that it just takes the contents and plops them straight into the path being resolved
surreal path
brub
why bro 
bro
how tf do i debug this
its clearly resolving the path
and its giving the vnode
so like
why tf
unkempt relic
there is a logging option that will tell you a bit more
surreal path
how to enable
surreal path
no i mean
how to enable this option
what do i do
oh wait
its a bool
yea trying to find
then it had tried to read
why is it failing on the read
wicked loom
does it even succeed to open the file?
tawdry mirage
it must've, it looks like its reading the elf ehdr
surreal path
it has a check
tawdry mirage
judging by the buf print
wicked loom
i guess you may try to open that file yourself in the kernel to see what happens, without relying on mlibc
surreal path
ill try printing some of the file data
ummm
ptr->type == NYAVNODE_SYMLINK is failing so
wtf
oh
its giving me back a directory
oh...
what am i supposed to do in this case
if it resolves to a directory
???
if the symlink resolves to a directory like
what am i supposed to do exactly
cause its resolving to /usr/lib/bash
surreal path
bru
surreal path
you just open the directory
yea and mlibc is trying to read the directory
???
like wha
surreal path
how
wicked loom
libstdc++ resolving to /usr/lib/terminfo makes no fucking sense
neither does anything else there
wicked loom
you tell me
wicked loom
nah, the tarball is fine
wicked loom
i trust GNU tar and i use the same script to generate tarballs and they generate fine
that's how i know
surreal path
lemme extract the stuff and see
wicked loom
but you can unpack and check for yourself
yeah
it's initramfs.tar, go to a different dir and run tar -xf <path to>/initramfs.tar
surreal path
bro im dying
why is that happening
why tf
what da helll
missing null terminator
OK I FIXED IT
wicked loom
nice cool
wicked loom
it's really simple
it's used to set FS basically
which is used for thread local stuff
but the sysdep is essentially just wanting you to do FS = arg
finite summit
if you want, you can use wrfsbase to write the fs base
instead of adding a syscall
wicked loom
yes but this is yet another microoptimisation and requires CPU support since that's not baseline
i would say just do a normal syscall and set it normally
finite summit
idk what ended up with him and deciding to ensure wrfsbase is supported
and failing otherwise
wicked loom
yes
well of course your scheduler needs to save and restore FS properly
if it doesn't already
wicked loom
cool
wicked loom
make sure you're not for some reason leaking kernel pointers to userland and expect it to be able to access them fine
if that is a page fault with that cr2, it suggests that's what's going on
you don't have KASLR on do you?
yeah you have it off
else the address would be different each time
surreal path
bro wtf
now its not resolving symlinsk
what
the
fuck
it just decided
to end its life
and stop resolving the symlinks
man i hate this
uh huh
bro
someone is modifying
my shit
and making my vnode
type
file
wtf
my kernel is cursed my kernel is cursed my kernel is cursed my kernel is cursed
does the fucking compiler not see this line
notneeded->type = NYAVNODE_SYMLINK
im done
im done
its not evening trying to resolve a symlink
its the heckin
sys_read
uh huh
okay i found that issue
it was the prepending
CLEARLY VALID FILE DATA
LIKE BRO
THE MEMCPY GOES FINE
like wtf
WHAT IS MLIBC DOING
HM?
???
seriously where is this address coming from
WHERE
surreal path
after further debugging it seems to be happening in the actual bash executable itself
tho i cannot addr2line it
or no
its not happening in bash
i dont know actually
cpl was 3 when this page fault happens
heres what we do know, the address is not something canoical at all. kernel never uses this memory so it cannot be a leak
i cannot addr2line this rip anywhere
cannot find in gdb
im very confused honestlyl
wicked loom
we'll sort it out later
like every bug you've hit before, they all seem silly in retrospect
surreal path
we'll sort it out later
but i need to sort it out now
ill print every syscall mlibc makes
okay very last thing mlibc does
syscall_fs
mmap is giving valid addresses
looks valid
yea fs base is fine too
so wtf is going on
bro
i dont see any type of memory leak
in all the addresses syscall_mmap
all userspace addresses
surreal path
i have no fucking idea
thorn bramble
what is the instruction at rip
surreal path
i cant addr2line it
thorn bramble
yes you can
thorn bramble
try harder
surreal path
bru
surreal path
before the fault
it likes does something for a few seconds no logging
then it faults
thorn bramble
lol fun
thorn bramble
you will !!!!
thorn bramble
log all the functions it's trying to run
you can modify the mlibc source code
add some prints
thorn bramble
log the function pointers
figure out which one makes it die
use gdb
figure out what exactly makes it die
you can put a breakpoint on it before jumping to userspace
thorn bramble
then (void*)...
surreal path
uh huh
thorn bramble
use objdump
and look for the last 4-5 nibbles
also look where libc.so is loaded lol
its not gonna be loaded at 0x40000000
that's the ld.so is loaded
surreal path
thorn bramble
logBaseAddresses should be good
thorn bramble
that is fine™️ iirc
surreal path
okay so
wtf is going on
this is fucking pain to debug
ill try breakpointing 0x4121abb0
thorn bramble
no idea i dont have your os built
i cant test it myself
hard to do remote debugging
surreal path
just build it 
thorn bramble
if i wanted to debug userspace i would just bring back my old zigux code
im gonna have to at some point
thorn bramble
zeroes!
surreal path
add %al, (%rax)
thorn bramble
0000
surreal path
funny
thorn bramble
idk maybe ur not reading in the library file into memory correctly
idk lol
also on that note, where tf are open+read calls?
i didnt see any in the syscall log you showed earlier
thorn bramble
show seek implementation
surreal path
kk
void syscall_seek(struct syscall_frame *frame, struct per_thread_cpu_info_t *ptr)
{
kprintf("syscall_seek()\n");
int fd = frame->rsi;
int offset = frame->rdx;
int flag = frame->r10;
struct process_info *pro = get_cur_process_info();
struct FileDescriptor *d = &pro->Descriptors[fd];
switch (flag)
{
case 0:
if (d)
{
d->offset = offset;
frame->rdx = 0;
frame->rax = d->offset;
return;
}
else
{
frame->rdx = -1;
return;
}
break;
case 1:
if (d)
{
d->offset = d->offset + offset;
frame->rdx = 0;
frame->rax = d->offset;
return;
}
else
{
frame->rdx = -1;
return;
}
break;
case 2:
if (d)
{
d->offset = d->ptr->ops->v_filesz(d->ptr) + offset;
frame->rdx = 0;
frame->rax = d->offset;
return;
}
else
{
frame->rdx = -1;
return;
}
break;
default:
kprintf("%d\n", flag);
kprintf("Flags are wrong?\n");
frame->rdx = -1;
return;
break;
}
}
thorn bramble
one "problem" i see is that v_filesz returns a size_t and idk how adding a negative int would work with that?
surreal path
okay then ill cast the size_t into an int
thorn bramble
it seems to work, nvm
green elbow
you can double check that the initArray pointer actually points to the correct place by logging it and checking the elf file with readelf -d
surreal path
you can double check that the initArray pointer actually points to the correct p...
oka
okay lets readelf
yea its correct
0xbf000
bro
this is clearly not a silly bug
finite summit
inb4 it's vmm shenanigans
finite summit
Well if it's memory being zeroed without anything telling it to be zeroed
Try setting hardware watchpoints on the affected address
Using the debug registers
Or fill in newly allocated addresses with some constant like 0xCC
surreal path
Well if it's memory being zeroed without anything telling it to be zeroed
i zero all memory
finite summit
Then if you jump to some bogus address that happens to be allocated nut untouched, instead of getting a bunch of add instructions, you'll get int3
surreal path
Try memsetting memory to 0xCC
ok
finite summit
In the vmm of course
surreal path
okay 0xCC
finite summit
If it is you jumping to uninitialized memory, you'll break using int3 instead of going to some random rip
surreal path
int3?
thorn bramble
breakpoint
finite summit
You know the int instruction
thorn bramble
finite summit
You know the `int` instruction
int3 is a shorthand for that
surreal path
okay so somewhere, do int3
surreal path
yes
thorn bramble
so instead of executing 00000000
you execute CCCCCCC
which is int3
and not some random add [rax], al
finite summit
Probably mlibc not zeroing memory on its own
thorn bramble
that is very possible
surreal path
bru
surreal path
why
surreal path
so itll just cause a page fault when it tries to execute the page
finite summit
so itll just cause a page fault when it tries to execute the page
Yeah
If it tries to jump to a bogus address
You'll need prot flags in some way for this to work
surreal path
okay fine
finite summit
You can't just set any page that should be executable to XD
surreal path
isnt the xd bit the last bit in the entry
finite summit
Bit 63
finite summit
But it's technically not guaranteed to be supported or enabled
finite summit
But it's technically not guaranteed to be supported or enabled
Limine enables it
But it's only unsupported on old cpus
thorn bramble
i prefer NX because XD makes me laugh (im mentally 12)
thorn bramble
yep that too
surreal path
how
finite summit
Check some bit of EFER to see if XD is enabled
thorn bramble
1 is of type int
surreal path
okay then cast to uint64
surreal path
okay and now i check prot if its executable
thorn bramble
i think unsigned long is 64 bits on 64 bits
surreal path
if its executble no xd
molten grotto
i think `unsigned long` is 64 bits on 64 bits
except if its windows 
but windows is weird anyways
kind root
llp64 
kind root
At least you shouldn't expect any destructive compiler optimizations
thorn bramble
pe+ kernel
finite summit
should be fun
Don't forget to make PE compatible bootloader
kind root
Just use the windows loader
finite summit
At least you shouldn't expect any destructive compiler optimizations
Or any new C features any time soon
thorn bramble
yea it should be fun, especially given that link.exe can link efi applications :^)
surreal path
okay and now i check prot if its executable
whats the bitmask for prot_exec
thorn bramble
so i can technically write it all and compile using windows tooling
i should use msbuild if i want it all to be extra shit
finite summit
whats the bitmask for prot_exec
Iirc you define these bits yourself
surreal path
no?
molten grotto
you have to conform whatever abi you use in mlibc tho (well you can still make your own abi but if you use one of the existing ones then you have to use the constants from that)
surreal path
im using the one copied by vinix
thorn bramble
most default sysdeps use linux abi now
surreal path
thorn bramble
probably linux abi then
surreal path
okay found
haughty kite
Don't forget to make PE compatible bootloader
you could probably convince limine to load that
or just use kernelcaches :^)
thorn bramble
good job
surreal path
just realized
molten grotto
well no
thorn bramble
oh wait is he accepting flags as uint8_t
molten grotto
yes
surreal path
yea just changed types
no page fault?
still err=4
bru
does qemu have xd bit support disabled
molten grotto
no
surreal path
weird
yea um
it maps some memory to not be executabl
to which
i do no problem
err still = 4
bru
bro like what the actual fuck
is going on
this is pain
mlibc just doesnt want me going to bash
green elbow
there is a >95% chance it is not mlibc's fault 
surreal path
this is hell
surreal path
bro
thorn bramble
he aint wrong tho
unkempt relic
i cant find this fuckin issue
what is the exact problem?
surreal path
what is the exact problem?
mlibc is jumping to some bogus address
even tho all memory i give to mlibc is 0'd and correct and valid addresses
unkempt relic
how bogus are we talking? something truly unforgivable like 0xc2ba349d66? or a slightly bogus address, like 0x430582
surreal path
lol
this
jumping to a bunch of instructions that literarly just
dont make sense
also all data using sys_read thats read into the buffer seems valid
surreal path
https://pastebin.com/M0tityE3
this is the full log
unkempt relic
lol
i want you to check whether that address seems to be legitimate with respect to bash (it looks like if bash is loaded at 0x40000 then that could be within it?)
surreal path
i believe its with libc.so
not bash
in which
the init array
is correct, bf000
could it be init_arraysz
its valid
no
wtf is going on
@unkempt relic do u have any idea whats going on
unkempt relic
<@391791686881247234> do u have any idea whats going on
those larger addresses do look like library addresses but the one that was closer to 0x40'000, which i believe is what you said was a problem, that one looks more bash to me
have you inserted a print after the DT_INIT_ARRAYs are all invoked?
surreal path
those larger addresses do look like library addresses but the one that was close...
i will do that
unkempt relic
because if we know that the problem is within one of the INIT_ARRAY functions then that is useful information
surreal path
it seems to be within one of the init_array functions
otherwise rtld would have printed complete
so this is within libc.so
this is the instruction
here
unkempt relic
are you single-core?
surreal path
yes
surreal path
why???
unkempt relic
i want to see what happens if you don't touch FPU state in the kernel at all
surreal path
oka
unkempt relic
keep SSE on you've only got one process that deals with it
unkempt relic
then we can be assured your FPU state management is not to blame for this
surreal path
yep
unkempt relic
(that's the only reason i asked, it got rid of one degree of freedom)
surreal path
this line
unkempt relic
let's find out where and why control jumps to this address
surreal path
unkempt relic
step through in GDB, instruction-by-instruction if necessary, until it jumps to the funny address
surreal path
okay
then it jumps here
to which it jumps here
more instructions
jumps here
now here
this is the instruction
that makes it jump to a funny address
0x491aa6
to these very invalid instructions
here
this new_set instruction
which is a macro
what do u think is happening @unkempt relic ?
unkempt relic
what do u think is happening <@391791686881247234> ?
when did it get to 0x49xxxx?
surreal path
i am unsure, i will run gdb again and see
this instruction
which makes it jump here
this instruction
is before it jumps to 0x49xxxx
here
what tf is going on
any ideas?
unkempt relic
this instruction
but that's not right
surreal path
i know
unkempt relic
you're sure that if you stepi when on this instruction, it jumps to 0x49xxxx?
surreal path
i used si
surreal path
you're sure that if you `stepi` when on this instruction, it jumps to 0x49xxxx?
yes
this is very weird
i have no further ideas on how to debug this further
unkempt relic
kindly p /x 0x412bffb0
surreal path
alr
this is the value
dereferencing the data gives
is that wrong @unkempt relic ?
unkempt relic
dereferencing the data gives
it's as expected
you could set a watchpoint in that address if you want
btw if you use add-symbol-file -o 0xloadaddress path/to/loaded/file you can see where you are in it in GDB
surreal path
you could set a watchpoint in that address if you want
how
unkempt relic
watch (void*)0xaddress (you'd want to do it early on and see where it's getting changed, add-symobl-file helps)
surreal path
clearly
nothing is modifying that address
so i do not know whats going on
hmmm??
unkempt relic
it's where it was changed to 0x491a80 that interests me more
surreal path
surreal path
here?
unkempt relic
now bt
unkempt relic
case R_X86_64_IRELATIVE: {
auto ptr = object->baseAddress + addend;
auto target = reinterpret_cast<uintptr_t (*)(void)>(ptr)();
*((uintptr_t *)rel_addr) = target;
break;
}
that's the relevant lines in mlibc (assuming you are using mlbic master or that the line numbers haven't changed much)
the question is why libc.so would want to jump to that address
surreal path
i do not know
maybe the people behind mlibc would know
does anyone know?
this is truly confusing
im stuck
does no one have any idea whats going on
please anyone
🙏
finite summit
Inb4 rewrite 2 of Nyaux
surreal path
no
molten grotto
could you regenerate the mlibc patch and push?
surreal path
could you regenerate the mlibc patch and push?
ok
surreal path
could you regenerate the mlibc patch and push?
patches are already pushed
molten grotto
ah yeah, I just had to delete the mlibc dirs to get them to update
molten grotto
I can't really figure out anything either, it just goes to some completely different code that is certainly not within the libc from the jump in getenv<plt>
surreal path
i know
surreal path
if u do find the issue @molten grotto let me know, im going sleep
unkempt relic
does bash provide a getenv?
molten grotto
actually yes it looks to be overwriting it
that would explain why it jumps there but idk why doesn't it show that address in gdb
molten grotto
I think this is some sort of memory bug as eg. 0x47fffc has a valid instruction from the bash executable but if you look at what there is when it dies there is just garbage there
surreal path
maybe the vmm is giving back that address cause of mmap_range
which doesnt create a region to mark that memory range as allocated
molten grotto
maybe the vmm is giving back that address cause of mmap_range
yeah looks like sys_mmap is indeed giving the same address where the executable is loaded because you don't ever mark it as used (and you don't use mmap_range there either)
so yeah you want to create a region when you load an elf that spans the range it uses (the first PT_LOAD phdr's pt_vaddr is always the start and the last PT_LOAD's pt_vaddr + pt_memsz is the end as they are ordered by the vaddr field)
surreal path
i will modify that when im not sick
right now im too weak to do anything
i feel like i might collapse my entire body hurts
surreal path
so yeah you want to create a region when you load an elf that spans the range it...
sorry im a little confused
but modify mmap range to create an allocated region correct?
molten grotto
I mean yeah you probably want that too, but you don't use mmap_range in the elf code
surreal path
why?
molten grotto
idk, you just don't
you could
I don't think you had mmap_range when you wrote the loading code
molten grotto
also MAP_FIXED actually does funny stuff like if there already is an allocated region that contains the range it tries to map using that flag then it splits the already existing region into different parts (possibly one from the start of the old region before the region range mapped with MAP_FIXED, one for the actual region range and then possibly one for the region from that range to the end of the old region)
surreal path
wha
tawdry mirage
if you MAP_FIXED over an existing mapping it replaces that part of the existing mapping
tawdry mirage
that is the intended behavior
surreal path
i will just not use mmap range
unkempt relic
for what it's worth you shouldn't have to worry too much about supporting MAP_FIXED yet, i didn't need it for mlibc loading, but of course you've got to make sure you don't allocate the areas that mlibc wants to map DSOs into
kind root
for what it's worth you shouldn't have to worry too much about supporting MAP_FI...
But mlibc tries to map fixed
unkempt relic
But mlibc tries to map fixed
i meant to say MAP_FIXED over existing mappings
kind root
Oh you mean that aspect of it
surreal path
for what it's worth you shouldn't have to worry too much about supporting MAP_FI...
i do not understand
unkempt relic
i do not understand
the ability to replace existing mappings detailed above
btw if it turns out you are giving out memory that was already mapped then that makes good sense
with regar dto the problems you experienced earlier
surreal path
yes
unkempt relic
that's zero
if you zero pages when you give them out then there's a working hypothesis on what's going wrong
surreal path
that is what i do
unkempt relic
the answer is simple then
make sure not to give out memory that was already mapped when mlibc has asked you to map some anonymous memory anywhere
surreal path
i think its because i do mmap_range in the elf loader
to whihc
doesnt mark the region as allocated
unkempt relic
and thus it gets intruded on
surreal path
yes
unkempt relic
then make sure it's marked allocated so it's not given out again
unkempt relic
i am not familiar with your kernel design
if the stack is loaded up there and your allocator allocaets from low addresses before high then it shouldn't be intruded on for a while
surreal path
if the stack is loaded up there and your allocator allocaets from low addresses ...
yes my allocator does low addresses before high
this is what i shall do
even marking it as allocated
still the same issue
wait
i know
ummm
great
clearly this didnt solve it
struct vmm_region *cur_node = maps->head;
struct vmm_region *prev_node = NULL;
uint64_t f = align_down(base + phdr.p_vaddr, 4096);
while (cur_node != NULL)
{
if (prev_node == NULL)
{
prev_node = cur_node;
cur_node = cur_node->next;
continue;
}
if ((cur_node->base) > f && (prev_node->base + prev_node->length) < f)
{
struct vmm_region *new_guy = kmalloc(sizeof(struct vmm_region));
new_guy->base = f;
new_guy->length = (align_up(phdr.p_memsz + misaligned, 4096));
kprintf("done\n");
prev_node->next = new_guy;
new_guy->next = cur_node;
cur_node = cur_node->next;
goto done;
}
else
{
// not enough space for our new region sadly, continue
prev_node = cur_node;
cur_node = cur_node->next;
continue;
}
}
done:
what i do
finite summit
nyaux rewrite /j
unkempt relic
clearly this didnt solve it
you could watch the 0'd address and see what happens
see whether it's supposed to be 0'd or not
if i were debugging it first i would objdump bash and check the address looks like there should be code at it
molten grotto
did you change the code to mark the region where the elf is loaded at as allocated? because I am 99% sure thats the issue
unkempt relic
did you change the code to mark the region where the elf is loaded at as allocat...
i think he said he did, i'm not sure
surreal path
did you change the code to mark the region where the elf is loaded at as allocat...
yep
you can see on the github @molten grotto that i clearly do that https://github.com/rayanmargham/Nyaux/blob/master/kernel/src/elf/elf.c
finite summit
I feel like it's a scheduler problem
surreal path
how
surreal path
still same issue
molten grotto
you can see on the github <@379250891838193667> that i clearly do that https://g...
I don't think that code is right
surreal path
I don't think that code is right
how
molten grotto
how
well for an example if there is no previous node you set current node to the next node and continue when you should put the new node at the head if you want to keep them ordered and you don't really care if the prev node base + prev node size is less than the base if they are ordered (well you could still do <= if you wanted as the end is exclusive)
surreal path
well for an example if there is no previous node you set current node to the nex...
im trying to keep them ordered, and there is always a node in a pagemaps region
always at least 2
molten grotto
Why do you add misaligned while rounding up
that is correct, for an example if the base is 0xFF0 and the length is 0x20 if you just align 0x20 to a page size you are going to get one page when in reality you must allocate two because the base isn't aligned
surreal path
im trying to keep them ordered, and there is always a node in a pagemaps region
see new_pagemap() in vmm.c
molten grotto
the points that I said still apply
surreal path
i am confused then
like
i dont get what is the issue with this
well for an example if there is no previous node you set current node to the next node and continue
molten grotto
then they aren't going to be properly ordered
for an example if head's base is 0x50000 and the node's that you are trying to insert is 0x40000
molten grotto
ah, in that case there is only the issue with using < instead of <=
surreal path
where am i doing <=?
molten grotto
you don't and thats the issue
surreal path
surreal path
ah, in that case there is only the issue with using < instead of <=
oh okay
something like this i suppose
OH MY FUCKIN GOD
OH MY
FUCK
IN
GOD
THANK U QWINCI
molten grotto
something like this i suppose
yes as eg. if previous base is 0x40000, previous length is 0xFFF and you are trying to insert a node at 0x40FFF it doesn't work
surreal path
yea i get u
molten grotto
likely it uses pthread mutex and that needs it
surreal path
well im happy we are closer to bash now
surreal path
likely it uses pthread mutex and that needs it
pthread mutex?
i dont have locks in my kernel so
do i just do nothing?
thorn bramble
happens
return ENOSYS from futex_wait/futex_wake
u should be able to get further
bash shouldnt need them
green elbow
sys_futex_wake
you can just make that return 0 if your OS is singlethreaded
mlibc uses locks internally by default
but if you don't have multithreading it's not needed
finite summit
so it turned out that it was ur vmm being shit?
I was right #1230349543623757845 message
surreal path
sorry guys im just
not having a good time rn
kinda hard to work on the project when some things happening irl
surreal path
i do want to work on it tho
i rlly do feel a passion for this project
just guess that this whole skipping school and everything just to work all day on nyaux is just not sustainable anymore
wicked loom
yeah that's probably a good call
but you can just work on it without skipping on the rest, just partition your time better
surreal path
fair lmao
wicked loom
prioritise your finals for now
surreal path
alr
surreal path
also yk u could probs get to userspace faster then me, if u knew exactly what u were doing probs under 24 hours
thats if u knew EXACTLY of what u were doing
but this was a from scratch kernel for me without any previous knowledge so 😃
random thought
hmm
why is mlibc trying to write to fd 2
tawdry mirage
stderr
surreal path
lmao
clearly bash is looking for things ig
now what is sys_dup
i have no fuckin idea
!!
tawdry mirage
return a new file descriptor referring to the same open file description
surreal path
but why
and also
ill have to make a new file descriptor that points to the same vnode
as i dont have that extra level of indirection
wide nexus
clearly bash is looking for things ig
did u recompile bash with mlibc?
wide nexus
ah I see
surreal path
what the heck is F_DUPFD?
surreal path
ok
oh bash didnt care that i errored out for sys_dup
it just continued ig
but now it wants fuckin
sys_tcgetattr
why
tawdry mirage
probably to set up raw mode on the tty for readline
tawdry mirage
it's configuring the terminal to disable line buffering and echo
since readline provides line editing on it's own
surreal path
do i just return -1
as i dont have a tty
im just writing everything directly to flanterm
tawdry mirage
not sure how well it'll take tcgetattr/tcsetattr failing
surreal path
well what else am i supposed to do huh
yea it didnt give a shit
now it wants sys_ppoll
which ill return -1
tawdry mirage
are you still ignoring fd 2?
tawdry mirage
well ig since poll fails, there's no way for it to get input
since bash does poll(stdin fd) => poll completes => read(stdin)
surreal path
okay then what should i do
unkempt relic
any bash prompt printed at all? did you implement isatty?
if bash thinks stdin is not a tty it will quit
surreal path
any bash prompt printed at all? did you implement isatty?
is a tty just returns 0
unkempt relic
because if stdin is not a tty then bash must be being used not as an interactive shell, but rather to run a script
tawdry mirage
if bash thinks stdin is not a tty it will quit
it'll still read it but in non-interactive mode
unkempt relic
is a tty just returns 0
i think that's what mlibc expects for a tty
surreal path
ig
tawdry mirage
i think that's what mlibc expects for a tty
yeah iirc ENOTTY is expected for not a tty?
unkempt relic
yeah iirc ENOTTY is expected for not a tty?
that's the one i think
surreal path
mr @elder shoal promised me this would be easy
tawdry mirage
small amount of syscalls doesn't mean you don't need to implement their functionality properly :^)
surreal path
i did tho for the syscalls he listed
he didnt include all these other syscalls
now bash wants poll
what am i supposed to return
unkempt relic
this is the tricky part of mlibc
elder shoal
he didnt include all these other syscalls
I didnt cuz I had just stubbed them lol
unkempt relic
it's so featureful that sometimes it gives you too much
but i think you can literally have poll just return ENOSYS and bash should happily deal
elder shoal
Yeah