IRC channel logs
2024-10-22.log
back to list of logs
<stikonas>Googulator: looks like bitmap fonts on the screen might not be copyrightable (at least in the US) <lanodan>well in arm/riscv/… world you could probably use serial instead of framebuffer-text, no? <oriansj>lanodan: same for most architectures; Although I doubt many people have a trusted VT100 terminal standing around. <fossy>stikonas: does riscv bootstrap still require gcc 4.7? rather than 4.0.4? <fossy>yeah, just thinking a good first step might be trying to strip 4.0.4 out <stikonas>though what do we do then with GCC 4.7.4? <stikonas>it's a bit pointless to build it with GCC 4.6 <stikonas>perhaps we just rebuild GCC 4.6 with C++... <fossy>ideally i think remove 4.0.4 and 4.7.4 and replace with 4.6.x dual-pass build? <fossy>sure, positioning of the builds doesn't erally matter <lanodan>oriansj: Well at least serial doesn't requires anything special to use multiple terminals (which can be relatively simple) and it's the kind of thing that allows to check logfiles, while VGA text… you need to trust your GPU. <lanodan>That said I do have a Minitel here that I could use as an hardware terminal but the baud rate settings can be a bit annoying with modern boards using speeds like 115200 as IIRC it's 9600 at most. <Googulator>oriansj: I wonder about the analog bandwidth requirements for UART <Googulator>As in, is it plausible to record UART traffic on tape? <Googulator>& then play it back and have it decode correctly <Googulator>Would be a cheap & easy solution to the problem of securely recording & reviewing logs <Googulator>As some of you might recall, I intend to optionally make builder-hex0 "verbose" by having stage1 print stage2's source, and then stage2 would print out any sources it decodes in cleartext from the srcfs. (Compressed files would be printed upon decompression; and then once we can spawn an interactive shell, such "firehose" printing would stop, in <Googulator>But to review such source code, a secure way of recording and replaying output would be needed. I initially thought of recording screen output on (possibly analog) video, but UART-on-tape might be even easier. <Googulator>I'm gravitating towards analog solutions here out of a concern that chips in a digital recorder could be subverted to hide backdoors in the logged code. <aggi>not sure if this question is appropriate here <aggi>for live-bootstrap you're patching musl-libc-1.1 with sigsetjmp.patch <aggi>this prevents a tcc_error("illegal displacement") when processing src/signal/i386/sigsetjmp.s:8 -> jecxz 1f <aggi>anyway, i applied this patch, and noticed some statically binaries to segfault, backtrace with gdb showing this was triggered by musl-1.1 sigsetjmp() function <aggi>ouch, hence, although your patch prevents a compile-time error, the change seems to cause a crash (couldn't diagnose this any further yet) <aggi>digging into tcc what's causing the compile-time error to address this instead is inconclusive too <aggi>to summarize, i can reproduce run-time crashes of binaries which seems related to the mentioned patch that's necessary currently <aggi>i would welcome some suggestion <aggi>to reproduce this, for example, a statically linked bash or oksh reliably show the segfault <stikonas>is jecxz not the same thing as cmp and je? <stikonas>JECXZ rel8 Jump short if ECX register is 0 <stikonas>so my understanding is that CMP ECX, 0 should check whether ECX=0 and if yes, set the flag in some register, then JE 1F will jump if flag is set <aggi>greetings stikonas, thanks for the reply <aggi>i have a suspicion, the value 0x1f could be interepreted as either short or int <stikonas>I just don't see what could conceivably cause a crash <aggi>but maybe you could help <aggi>to my knowledge, there is a some syntax prefix to explicitely label some value as short/int/long <stikonas>I don't even see yet, where tcc defines "je" <aggi>and i would like to try jecxz <shortprefix>1f <aggi>but i don't know the syntax of this <aggi>and well, i don't know myself why a bash.static compiled/linked against musl-libc-1.1 with i386-tcc would crash in sigsetjump <aggi>ah, ok, maybe that's why tcc_error("illegal displacement") is emitted compile-time (without your patch) <aggi>i386-asm.h: DEF_ASM_OP1(jecxz, 0xe3, 0, 0, OPT_DISP8) <aggi>asm-i386.c:1072 tcc_error("invalid displacement"); <aggi>which is related to the jump distance not being recognized as "short" i suspect <aggi>hence the idea to prefix the value 0x1f as short explicitely, which some asm syntax exists for, which i don't recall which it was <stikonas>well, syntax might exist, but the question is whether tcc understands it <stikonas>so jecxz has OPT_DISP8, /* Like OPT_ADDR, but only 8bit (short jumps) */ <aggi>i think it does, some of it; and it's just a first lucky trial and error <stikonas>aggi: how about if you replace 1f with 1 ? <aggi>confusing, no clue, i might try <aggi>the relevant issue is some tcc-compiled stuff segfaults in sigsetjmp <aggi>which may or may not be related to the patch <stikonas>and step through the assembly instructions <stikonas>"layout asm" followed by "layout regs" might help a bit too <aggi>stikonas: i don't want to flood this channel <aggi>but here's a few more bits and pieces <aggi>0x8085318 <sigsetjmp+4> cmp %ecx,0x0 <aggi>that's where gdb halts, followed by the je instruction, right at the spot the patch applied <stikonas>I don't think it can ever cause segfault <stikonas>I could see how je could jump somewhere illegal <aggi>ok, thanks for the gdb hints; don't want to waste your time stikonas