Greetings, while testing tinycc with compiling a complete i586-tinycc-linux2-musl.iso distribution several test-vectors were covered:
I) BUILD=HOST=TARGET=i386 - with such tinycc (cross-)compilation setup a complete distribution compiles, links, boots and runs mostly flawless already $ file /usr/bin/tcc /usr/bin/tcc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, with debug_info, not stripped $ /usr/bin/tcc --version tcc version 0.9.28rc 2025-02-13 HEAD@f8bd136d* (i386 Linux) - this setup didn't cause any notable trouble (musl libc patched for linux2.4 syscall abi as announced recently etc) II) expanding test coverage with BUILD=aarch32 HOST=i386 TARGET=i386 - tinycc with --enable-cross was compiled by gcc4.7 providing a functional i386-tcc cross compiler binary $ file /usr/bin/i386-tcc /usr/bin/i386-tcc: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped $ /usr/bin/i386-tcc --version tcc version 0.9.28rc 2025-02-13 HEAD@f8bd136d* (i386 Linux) - then for sake of simplicity all tinycc compiled binaries are statically linked - however with this setup i386-tcc produces some (not all) mis-compiled binaries which segfault on either x86 linux2.4 or linux5.10 kernel for example: /bin/oksh (openbsd posix shell) or /usr/bin/dbclient (dropbear ssh client) $ file /usr/bin/dbclient /usr/bin/dbclient: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped - gdb doesn't disclose any helpful hint yet $ gdb /usr/bin/dbclient GNU gdb (GDB) 7.12.1... (gdb) run Starting program: /usr/bin/dbclient Program received signal SIGSEGV, Segmentation fault. 0x0808d5ae in __stdio_read (len=1, buf=0xbfffe83b "\bh\350\377\277\020\301\t\b@p\v\b\003", f=0x80b7040) at src/stdio/__stdio_read.c:22 22 src/stdio/__stdio_read.c: No such file or directory. (gdb) backtrace #0 0x0808d5ae in __stdio_read (len=1, buf=0xbfffe83b "\bh\350\377\277\020\301\t\b@p\v\b\003", f=0x80b7040) at src/stdio/__stdio_read.c:22 #1 0x0809bac1 in __uflow (f=0x80b7040) at src/stdio/__uflow.c:9 #2 0x0809c110 in getdelim (f=0x80b7040, delim=10, n=0x80b5cc0 <size>, s=0x80b5ca0 <line>) at src/stdio/getdelim.c:62 #3 0x0808ee5c in getline (f=0x80b7040, n=0x80b5cc0 <size>, s=0x80b5ca0 <line>) at src/stdio/getline.c:5 #4 0x0808bb52 in __getpwent_a (res=0xbfffe934, size=0x80b5cc0 <size>, line=0x80b5ca0 <line>, pw=0x80b5ca4 <pw>, f=0x80b7040) at src/passwd/getpwent_a.c:19 #5 0x0809a84c in __getpw_a (res=0xbfffe934, size=0x80b5cc0 <size>, buf=0x80b5ca0 <line>, pw=0x80b5ca4 <pw>, uid=0, name=0x0) at src/passwd/getpw_a.c:36 #6 0x0808ba5c in getpwuid (uid=0) at src/passwd/getpwent.c:28 #7 0x08062cbf in fill_own_user () at src/cli-runopts.c:780 #8 0x080620c4 in cli_getopts (argv=0xbfffea24, argc=1) at src/cli-runopts.c:202 #9 0x0805fae9 in main (argv=0xbfffea24, argc=1) at src/cli-main.c:60 - src/stdio/__stdio_read.c:22 seems some arbitrary spot within musl-libc 1.1.24 which finally errors out - to compile musl-libc in mentioned cross-scenario one patch to tinycc was necessary (see attachment), not sure if this is causing the problem - build logs of tinycc itself, musl-libc, oksh or dbclient mis-compiled binaries can be provided if needed - seems some memory is read/written illegally, got no better description at hand - so far the problem with i386-tcc only occurs when it's compiling on some BUILD=aarch32 host for TARGET=i386 - i can with 99% certainty rule-out any wrong header or library was linked against, and i've spotted another mis-compiled binary from arm-tcc itself (zic utility from timezone-data for example, that worked flawless when compild with i386-tcc), hence i suspect aarch32 being involved is a little flaky overall, which i had noticed with some other test-case when compiling linux2.4 kernel too: https://codeberg.org/aggi/linux-tcc/src/branch/master/README "Currently it is recommended to execute Kbuild.sh on a native x86 build host" - However the current cross-compilation test setup mentioned could be the most easily re-produced and reported; because with any other various tinycc-versions were involved, and difficulties to isolate problems (an ELF binary is easier to attach a debugger to than a kernel image etc) The cross-compilation scenario (II) was established to extend test-coverage for tinycc, it is not causing any blocker to proceed with i586-tinycc-linux-musl.iso development. Nonetheless the idea was, such system could be cross-compiled from any system which got ready tinycc cross-compilers. Currently this would work on some native x86 build-host only, not aarch32. Not sure if this problem is specific to aarch32. Another problem however, which was outlined: https://lists.nongnu.org/archive/html/tinycc-devel/2025-03/msg00029.html python/portage cannot be supported with tinycc yet, hence i consider rewriting the entire packaging of ~550 builds _without_ relying on python/portage, including cross-compilation support. Hence the verification of cross-compilation with tinycc beyond different ARCH was desireable. So far, the test-vector mentioned with scenario (II) did fully pass compile-time, but run-time many mis-compiled binaries were produced. -- Michael Ackermann
diff --git a/tccgen.c b/tccgen.c
index b7d35ba7..3ad95a53 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -7780,7 +7780,7 @@ static void init_putv(init_params *p, CType *type,
unsigned long c)
; /* nothing to do for 0.0 */
#ifndef TCC_CROSS_TEST
else
- tcc_error("can't cross compile long double constants");
+ tcc_warning("cross compiling long double constants");
#endif
break;
signature.asc
Description: Digital signature
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
