IRC channel logs
2022-08-21.log
back to list of logs
<oriansj>in First_pass you seem to call instead of jump to StoreLabel which ends with jmp First_pass; so that'll result in a growing stack <stikonas>oriansj: oh, maybe it's just a stupid thing <stikonas>I have not set amount of memory in qemu command line <oriansj>but it'll mess with returns inside of your code <stikonas>anyway, I'm fixing it, it needs fixing in any case <oriansj>as when you hit EOF, it'll just return to First pass <oriansj>for as many times as you called StoreLabel <stikonas>increasing qemu RAM makes problem less severe but it is still there <stikonas>I probably had to run hex2 30 times more to hit the bug <stikonas>although maybe I shouldn't have pushed QEMU ram increase just yet... <oriansj>GetTarget you have: mov rdi, [rip+scratch] don't you mean mov rdi, rip+scratch (or the LEA eqv) <stikonas>hmm, I don't think "mov rdi, rip+scratch" is legal <oriansj>and we are wanting the address at table to read from, not the contents at that memory address <stikonas>that in uefi version scratch label holds memory address of malloced pool <oriansj>as the operations that follow would be setting that and reading it but doing mov r*, [value] could result in arbitrary memory being used unless you set that value yourself first <stikonas>but it's plausible that something in those functions is not adjusted <oriansj>well the best news is those changes can be tested on POSIX too <stikonas>yes, but Linux kernel might be more robust <stikonas>and freeing resources when process exits <oriansj>well if the diff between the POSIX and the UEFI version is just the setup and the syscalls, it'll really limit the number of spaces where things have gone wrong <oriansj>and debugging on posix is much easier <oriansj>so perhaps do a [rip+###] on POSIX and then do a copy/paste? as you'll ensure all the core logic is correct <oriansj>jesus rust/cargo is insane; I need a nightly rust compiler but also the stable rust compiler to build a 932line rust program <aggi>and llvm/rust themsleves require hours to compile <oriansj>aggi: even days if you are on a limited RAM system and have to page out to spinning disk <aggi>oriansj: i use cortex a53 SBC... and g++ hitting OOM regularly was one reason to remove all of it, and blocking at gcc47 <aggi>next idea, was, to utilize a tcc-toolchain <aggi>and a few hundred LoC of aarch32 ASM break the whole idea of i <aggi>i mean, it is possible to move aarch32 GNU gas implementation into arm-tcc... however that's the opposite of the design principle of tcc, to remain small and as simple as possible <oriansj>well there is no universal assembly standard, so it is mostly what arbitrary crap someone defines and who else copied it <aggi>a tcc-toolchain and and complete linux distribution has huge potential <aggi>for self-hosting embedded development, a fully capable linux developer system, on a raspi zero 1.3 type system, available for $5 <aggi>i mean, i could simply set AS=binutils-as, that's one variable changed inside the build scripts <aggi>however, i do not want to lock into GNU binutils _without_ a reasonable alternative available <aggi>and the progress made by bootstrappable.org with i386 tcc and musl-libc-1.x is remarkable, however i am not willing to move to x86 either <aggi>and i think, it is not at least possible/feasible to implement a reasonable aarch32 assembler alternative <oriansj>aggi: that is fine, just realize progress to additional architectures will certainly take time and much more effort <aggi>oriansj: i rather programm with a Z80 then enjoying any more of the innovation and progress <oriansj>aggi: if someone can be implemented once, it can be done so again. It just requires someone willing to burn a year or two to get it done <aggi>and it is, currently, beyond my abilities <oriansj>and we are more than willing to help expand people's abilities <oriansj>to the level where you could create anything you wanted. <aggi>currently i am thinking to play with Z80 <aggi>however, whatever i do, i simply cannot afford to invest years of work for this <oriansj>when I get back to M3 work, it should cover your use case and if you help test and report bugs the work would go faster <aggi>i don't think it's worth the effort, to waste precious development manpower to re-implement aarch32 GNU gas in arm-tcc <oriansj>aggi: well M3 is supposed to be a binutils drop in replacement with only the minimal feature/functionality subset needed and buildable by M2-Planet as a design goal <oriansj>and as it is my time, it is mine to waste in any way I see fit <oriansj>I don't expect anyone else to use it or even care; I build these things because they look like fun and bootstrapping is a huge amount of fun and enjoyment for me <fossy>stikonas[m]: making progress. rn im trying to get drone ci working properly <fossy>(ik that its timing out but this is re: the newlines after every character for no reason haha) <aggi>today i archived the tcc-toolchain/userspace containing those ~600builds; as soon as some particular bureaucratic hindrances for me to work and live in germany are settled i'll publish <stikonas[m]>fossy, I don't think I can get to your link, I get connection dropped <fossy>fosshost has something configured wrong on their firewall or somthing, it drops out from time to time and comes back if you poke it enough <stikonas>hmm, yes, even log output seems messed up <stikonas>can't see anything obviously wrong in yml file but I haven't used drone before <stikonas>fossy: if I download the logs, newlines are fine <stikonas>fossy: maybe that's how done view works? <stikonas>early steps in stage0-posix a printed one byte at a time <stikonas>hmm, though it also happens in earlier stages (seabios...) <fossy>stikonas: aha, it was some random ansi control code that the web view didn't like, just piped it through ansi2txt which strips all those random control codes and leaves with raw text <oriansj>stikonas: well it is possible to buffer input and output without much additional complexity for reducing the number of syscalls/interrupts and improve performance <oriansj>In the DEBUG.exe version of hex0, the file is loaded into memory by DEBUG.exe and the resulting block of memory is written to disk on exit <stikonas>anyway, it looks like fossy had different issue.... <stikonas>oriansj: I've pushed those changes to stage0-posix-amd64 to convert hex2 to position independent code <stikonas>(and use allocated memory for scratch area) <stikonas>so far can't see anything wrong on posix... <stikonas>oriansj: hmm, I might have accidentally fix that hex2.S bug... <stikonas>"mov rcx, r12 # arg1 = structs" was not pointing to the beginning of reserved area <stikonas>so at the very least I learned that we really need to cleanup up after ourselves in UEFI