<oriansj>stikonas: that is mkdirat; not mkdir <oriansj>but it does look like we are setting the wrong registers <oriansj>as we only need to set X1 and X0 (with the syscall in X8) <oriansj>pretty easy to use GDB to confirm that <oriansj>USA-RedDragon: if you would like I can talk you through the process <oriansj>as all C functions output by M2-Planet have FUNCTION_ prefixes and if you used blood-elf, you can just set a breakpoint at FUNCTION_mkdir <stikonas>oriansj: as far as I can see, aarch64 does not have mkdir, only mkdirat <stikonas>and stage0-uefi changes pushed (now reaches M1-0) <stikonas>I've skipped blood-elf as it's not immediately useful <stikonas>we can maybe build blood-elf once we have full non-bootstrap M2libc <stikonas>in case somebody wants to build debug POSIX binaries on UEFI <oriansj>USA-RedDragon: your SET_X2_FROM_X1 define decodes to: orr x2, xzr, x1, lsl 8 and no arguments are passed to functions via registers (they are passed on the stack) <oriansj>so you probably want to use e20301aa <oriansj>(you can verify it with: rasm2 -a arm -b 64 -d 'e20300aa' if you would like) <oriansj>stikonas: well we could figure out the debug format for PE binaries and then our UEFI binaries can be debuggable as well <USA-RedDragon>But that's alright, that part is going to get reverted anyway <oriansj>just install radare2 and you can also do things like: rasm2 -a arm -b 64 'mov x2, x1' <oriansj>that way you don't depend upon a web service to lookup instruction encodings/decodings <oriansj>stikonas: Well I did pull these syscall numbers from the Linux kernel itself about 3 years ago but I can't image they removed public syscalls unless no one was using them or they were non-functional <oriansj>USA-RedDragon: If the pathname given in pathname is relative, then it is interpreted relative to the directory referred to by the file descriptor dirfd (rather than relative to the current working directory of the calling process) mov x0, #-0x64 translates to: mov X0, AT_FDCWD <oriansj>which just ultimately just causes mkdirat to behave exactly like mkdir <stikonas>oriansj: not sure if it's that easy, I briefly looked, addind debug sections might make UEFI not run them <stikonas>so one would still have to connect with external gdb <stikonas>but I found that radare2 (at least on amd64) often gives wrong answers... <stikonas>so it might be good to use it but double check with web server <stikonas>actually, the way risc-v was implemented, I didn't have to use anything at all <stikonas>so that's nice, though at the expense of more complicated hex2 (but that was unavoidable on riscv) <oriansj>stikonas: well gdb can also be used to disassemble a binary while you run it <stikonas>anyway, debug binaries can be left for future improvement if somebody bothers <oriansj>stikonas: completely fair as it looks messy <stikonas>which only works for x86, not even amd64 <USA-RedDragon>Ah I see why mes failed. Comment in the kaem file says "# Restore once mes adds arch specific kaem files". I know my next task <stikonas>USA-RedDragon: that might have been done already <stikonas>there was one recently and I've already pushed it into live-bootstrap <stikonas>kaem automatically exports all it's variables to child processes <oriansj>USA-RedDragon: yes, kaem will use any environment you give it <stikonas>hmm, for UEFI we'll have to do som ifdefs here... <stikonas>to implement passing of environmental variables and also don't do forking <oriansj>well the lack of forking presents a serious problem for a shell. <stikonas>well, should still be possible to implement <stikonas>we can spawn other processes, so just need to correctly pass command line options and env variables <stikonas>I wonder how hard would it be to add an optional interactive mode to kaem <stikonas>(possibly without any editing capabilities) <stikonas>probably not too hard though for now not high priority <oriansj>the following: struct termios' definition, the function isatty, the function tcgetattr, the function tcsetattr and the #defines for BRKINT | ICRNL | INPCK | ISTRIP | IXON | OPOST | CS8 | ECHO | ICANON | IEXTEN | ISIG | TCSAFLUSH | VMIN | VTIME <muurkha>oriansj: PDP-7 Unix implemented exit() by execing the shell <muurkha>so it could run an interactive shell without forking <muurkha>because the PDP-7 didn't have virtual memory, not even a base register, forking was quite a heavyweight operation that involved dumping the computer's memory out to a disk. likewise context switches <stikonas>when I said we have no forking, I meant no fork() type of call that makes a clone of process <muurkha>right, because it's from the VMS→WindowsNT→UEFI lineage <muurkha>which doesn't have execve() or anything similar either, does it? <stikonas>no, there is only LoadImage function and then StartImage <stikonas>there is a call for exiting too but it's optional <stikonas>you can just do return and it goes back to the caller <muurkha>StartImage is sort of like execve() I guess <oriansj>good thing M2-Planet supports #ifdef statements <stikonas>or at least we can implement execve that way <stikonas>hmm, I wonder if we can then somehow fake fork call... <stikonas>then it will think that it's a child and do execve (start image) <stikonas>not sure if that's the best way, as it is a bit against the spec <muurkha>implement fork to be setjmp() and return 0, and exit() to be longjmp? :) <stikonas>probably less hacky way, is to just #ifdef the whole fork/execve stuff and just add spawn function... <stikonas>hmm, interesting, I think mkdir in UEFI is just open call <stikonas>with create atribute (but we already use it for files) <oriansj>stikonas: actually spawn would be in the #ifdef and the fork/execve bit would be inside the #else block <stikonas>anyway, I'll probably do it in smaller bits <stikonas>first get enough to build hex2 and M1 from C sources <stikonas>that will need far fewer things than kaem <oriansj>although you really should do an announce for getting M2-Planet self-hosting on UEFI; as you might be right about it being the first self-hosting Compiler to run on UEFI <oriansj>stikonas: could we use EFI_GLOBAL_VARIABLE as environment variables? <oriansj>we only need them to persist for the duration of kaem's life <stikonas[m]>Though finding out what to read withGetVariable is tricky <oriansj>that should simplify passing an environment to a process <oriansj>fortunately we know exactly what environment variables are available/used <oriansj>and once we have process execution, M2libc will become the most powerful C Posix library for UEFI <oriansj>we have fcntl.c, signal.h, stddef.h, our stdlib.h is bigger and our stdio.h supports more <oriansj>the only bits they have which we don't are: qsort.c and time.c ***lanodan is now known as Guest8010