MahnoKropotkinvich/tinycc
1
0
Fork 0
mirror of git://repo.or.cz/tinycc.git synced 2026-06-17 15:44:18 +08:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

docs: add lesson learned - arm64 win32 run validation

Browse Source
This commit is contained in:
Benjamin Oldenburg 2026-04-04 21:29:15 +07:00
parent 2d07e45370
commit 42d85ec622
1 changed files with 7 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
.docs/lessons_learned.md
View File

@ -39,3 +39,10 @@ Root Cause: `win32/lib/crt1.c` rebuilt run arguments from the original process c
Solution: Rebuild `-run` argv from the active CRT `__argc`/`__targv` slice first, keep wildcard expansion on that slice, guard `tcc.c`'s `run_arg_start` write behind `TCC_IS_NATIVE`, route `_runtmain` through generic `atexit`/`__run_on_exit`, and keep `_tstart` on `__tcc_exit` so normal executable destructors still run.
Prevention: For Windows runtime changes, rerun both nested `make test` coverage (`tests/test2`, `tests/test3`) and the Windows-specific lifecycle tests (`tests/tests2/108_constructor`, `tests/tests2/128_run_atexit`). Do not assume ARM64's `runmain-arm64.S` shims behave the same as x86_64's `lib/runmain.c`; they exercise different cleanup paths.
Related Files: [win32/lib/crt1.c, tcc.c, lib/runmain.c, win32/lib/runmain-arm64.S, win32/lib/runrt.c, tests/Makefile, tests/tests2/108_constructor.c, tests/tests2/128_run_atexit.c]
Date: 2026-04-04
Problem: The new Windows ARM64 `-run` regression initially failed for unrelated reasons: libtcc was loading stale x86_64 helper objects, and the custom regression source could not find the Windows CRT headers it actually uses.
Root Cause: The top-level `configure` + `make` ARM64 flow rebuilds `tcc.exe`, `libtcc.dll`, and `arm64-win32-libtcc1.a`, but it does not refresh the `win32/lib/runmain.o` and `win32/lib/libtcc1.a` support files that libtcc resolves through its library path during Windows `-run`. This repo already had older x86_64 ELF support objects in `win32/lib`, so validation used the wrong architecture until `win32/build-tcc.bat -t arm64 -c clang` regenerated them. The regression harness also needed `win32/include` in addition to `include` because TCC's Windows headers provide `string.h` there.
Solution: Rebuild the Windows support tree with `win32/build-tcc.bat -t arm64 -c clang` before running ARM64 libtcc `-run` validation, and add both `.\include` and `.\win32\include` plus `.\win32\lib` to the regression harness setup.
Prevention: After changing Windows `-run` or libtcc startup code, verify the architecture of `win32/lib/runmain.o` and `win32/lib/libtcc1.a` before trusting failures. If the test is meant to exercise Windows hosted compilation, include `win32/include` explicitly instead of assuming the generic `include` tree is sufficient.
Related Files: [win32/build-tcc.bat, win32/lib/runmain.o, win32/lib/libtcc1.a, win32/test_run_arg_cleanup.c]