IRC channel logs
2024-10-23.log
back to list of logs
<mihi>stikonas, the main difference between "jecxz" and "cmp ecx, 0; je" (or more often "or ecx, ecx; jz") is that the former does not clobber the flags. Looking at the code, assuming that __sigsetjmp is entry point of sigsetjump function, I don't see why that would be needed. <matrix_bridge><Andrius Štikonas> mihi: well, it was tcc failing to compile it <mihi>aggi, most likely the segfault is caused by the previous instruction which reads an argument from the stack. <matrix_bridge><Andrius Štikonas> But these patches are from very early times in live bootstrap <matrix_bridge><Andrius Štikonas> There were more but I cleaned up at least one hack already <mihi>aggi, the "1f" does not refer to the hex value, it is a "forward label", jump to the next label 1 that is found forward in the code.. <mihi>it allows to use the same label more than once in the full assembly code. <mihi>stikonas, I'm pretty sure your fix is correct. And I assume that the problem is that jecxz is not available with wider relative offset than 8 bit, so if the code between the jump and the label ends up to be more than 128 bytes, there is no way to correctly assemble it. Or maybe tcc miscalculated the jump. je, on the other hand, is available in all "widths". <stikonas>at least with gcc, it's a jump from 0x4 to 0x2a <aggi>stikonas: i've found the problem and the solution to sigsetjump.patch for musl-libc-1.x <aggi>however, i have no clue how this bug couldn't have been triggered before, with the patch applied, to support tcc with musl-libc <aggi>all of the sudden i'm encountering runtime segfaults, while maintaining ~500ebuilds for support with tcc-toolchain <aggi>that's a problem, because i have to prioritize time and effort for each individual ebuild <aggi>which raises the question, how such a libc patch could have passed, because it reliably segfaulted bash and oksh <matrix_bridge><Andrius Štikonas> Well, it didn't segfault on bash scripts that were run on live bootstrap <matrix_bridge><Andrius Štikonas> Anyway, we still don't know what the issue was unless you share your fix <aggi>anyway, i got ~500ebuilds passed compile-time with tcc-toolchain statically linked (except kernel, except whatever would segfault run-time) <aggi>including monstrosities such as mplayer, mutt mailer, and a few development utilities <aggi>i think, i486-tcc-linux-musl.iso is feasible, to utilize that as development host, including whatever bootstrappable was interested in <aggi>sadly, this is what i'll continue with next, i can't statically link python and perl with tcc, not yet <aggi>replacing ncurses with netbsd-curses, another one <aggi>maybe the hotfix too was related to dynamic /lib/ld-linux.so loader segfaulting <aggi>don't know yet, but if i got back dynamic linking support, i too can salvage perl/python/portage/autotools <aggi>ssl.h sucks too, to keep it leightweight and comprehensible <aggi>but that's outside the realm of interest of bootstrappable <matrix_bridge><Andrius Štikonas> I can't understand how anything could have worked there then <matrix_bridge><Andrius Štikonas> Unless we never used sigsetjmp function... <aggi>gdb-7.12 compiled/linked with tcc segfaulted too, maybe that's gone too now ... i don't want to miss gdb <aggi>i'll launch another crossdev, with the patch applied, seeing to what happens next <aggi>fyi, i patched tcc itself, to sanitize header/lib search paths for cross-compilation, to ensure 100% nothing is leaking from host into target <aggi>which is what disclosed a few more irregularities, including the sigsetjmp, because host libc linkaged leaked into target before <aggi>while i can ensure linkage against a 100% sanitized tcc crossdev-root <aggi>Your IP address <***> has been blocked for violating the dpaste.com Terms of Service... wtf <aggi>^ with this you can override CPATH and LIBRARAY_PATH to ensure nothing leaked from HOST into TARGET <aggi>assuming you knew what you were doing while testing your patches <aggi>because, i had hit the sigsetjump segfault when the tcc crossdev-root was fully sanitized to prevent leakage <aggi>before, chances were, host libc was linked against instead of target libc <aggi>stikonas: maybe that's why ? <matrix_bridge><Andrius Štikonas> No, there is no way host libc was used in live bootstrap <matrix_bridge><Andrius Štikonas> So bare kernel and just initramfs with bootstrap seeds and sources <aggi>with the minor change to sigsetjump, a gdb-7.12 statically compiled/linked with tcc too works it seems, no more segfault <aggi>i have to see, maybe musl libc.so dynamic loader won't segfault anymore either, and i got back dynamic linking/loading support then