Error: Cannot generate most of the files due to memory area overflow #126

Activity

1. JC-000

   added a commit that references this issue on Aug 22, 2026

   Merge pull request #127 from JC-000/fix/https-target-rodata-segment

   ...

   9973f8a
2. JC-000

   closed this as completedin #127on Aug 22, 2026
3. JC-000 commented on Aug 22, 2026

   

   JC-000

   on Aug 22, 2026

   Owner

   More actions

   Fixed and merged in #127 — git pull and your command builds.

   What was actually wrong

   Two red herrings worth naming, because both would send you the wrong way:

   • LIB_NISTCURVES_P256_RODATA didn't grow. It got pushed off the end of the region by something else.
   • HTTPS_BODY_TO_REU=1 is innocent. Isolating the flags, the cause is HTTPS_HOST / HTTPS_PATH alone — 46 bytes of extra string.

   HTTPS_HOST / HTTPS_PATH / HTTPS_SNI are the only rodata in the program whose size is a build knob, and they sat in RODATA, which every cfg routes into the always-resident crypto region. That region is nearly full:

   profile	region	free at default host/path	your command
   uci plain	CRYPTO_HOT	12 B	FAIL by 34 B
   uci onchip	CRYPTO_HOT	25 B	FAIL by 21 B
   uci comb	CRYPTO_HOT	—	OK
   ip65 plain	CRYPTO_RESIDENT	120 B	OK
   ip65 onchip	CRYPTO_RESIDENT	10 B	FAIL by 36 B

   So 46 B of hostname pushed the sibling library's rodata past $9FFF, and the link died in a segment that has nothing to do with the flag you set.

   You found something worse than a one-command failure: two of the three shipped products (uci-onchip, ip65-onchip) could not build this at all. The wikipedia milestone was reachable only because the comb cfg already routes RODATA elsewhere — so the flow worked on exactly the one profile it was developed on.

   The fix

   The three strings now live in their own HTTPS_TARGET_RODATA segment, routed per-cfg to a region with room — CRYPTO_OVERLAY under both UCI cfgs (~2.5 KB free), NET_CODE under ip65 (186 B tail). Growth in a build flag now hits that flag's own budget instead of an unrelated library's rodata.

   All five profiles build your command now. All three UCI profiles also build at the asserted maxima at once (63-char host + 100-char path + 63-char SNI).

   One limit worth knowing if you use ip65: its 186 B is a joint budget, and the 63/100/63 asserts in boot.s are independent maxima, not a joint guarantee. Host + path at maximum is 165 B and fits; adding a 63-char HTTPS_SNI on top is 229 B and overflows by 45 B. HTTPS_SNI is a UCI-era relay/forensics knob so that isn't a real ip65 config — and it now fails naming HTTPS_TARGET_RODATA and its own region, rather than pointing at a library that didn't grow.

   Verified

   • All five profiles build your exact command (was 3 of 5 failing).
   • tools/test_http.py in VICE: 66/66 on uci (including the REU-sink vectors), 61/61 on ip65. tools/test_tls_handshake.py: 21/21.
   • Segment placement confirmed in the map for the uci-comb wikipedia build.

   Not verified: no U64E run this session, so the wikipedia fetch itself is re-checked as far as the link and the VICE suites, not end-to-end on hardware. If you run it on a device and it misbehaves, reopen — the strings moved address, and that's the thing a hardware run would catch that a link cannot.

   Thanks for both reports — #124 and this one each turned up something real.