Emery/Gabbro apps are capped at ~64K virtual_size everywhere, despite docs/tooling advertising 128K

[truhanen]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

pebble build for Emery reports:

Total footprint in RAM:         60232 bytes / 128.0KB

Padding the same app's .bss by 8KB (60232 -> 68440 bytes) makes the next build step fail instead:

Exception: App virtual size is 68440 bytes (.text + .data + .bss).
Must be 65535 bytes or smaller, because PebbleProcessInfo.virtual_size is a uint16_t.

Firmware duplicates this cap unconditionally, regardless of platform:

app_storage.c's APP_MAX_SIZE = 0x10000, checked in app_storage_get_process_info() before process_loader_storage.c's own correct, platform-aware virtual_size > segment_size check (Emery's real segment is 135168 bytes / ~132KB, per Kconfig's APP_RAM_EMERY_SEGMENT_SIZE) ever runs.

So every layer — SDK build tool and firmware — actually enforces ~64K for Emery/Gabbro, same as Basalt/Chalk/Flint, despite ~2x the real RAM and despite the build report and official docs ("Max App Size: 128k") both claiming 128K.

Expected Behavior

Either Emery/Gabbro can use meaningfully more of their real ~132KB segment for code+data (needs virtual_size/load_size widened from uint16_t, and the app_storage.c check fixed/removed), or the report and docs should say 64K, not 128K.

Steps To Reproduce

1. pebble build an Emery app; note the reported "X / 128.0KB".
2. Add an 8KB static buffer, referenced once (e.g. from init()) so it isn't optimized out, pushing virtual_size just over 65535 bytes.
3. pebble build again — it now fails with the uint16_t error above, contradicting the 128KB figure the same app reported a moment earlier.

Version

v4.33.0-24-g70c24aa86 (Pebble SDK 4.33.1 / pebble-tool 5.0.39)

Host OS

macOS 15

Watch

Pebble Time 2 (Obelix)

Anything else?

Reproduced via the build pipeline + firmware source; not tried on real hardware, since the build tooling itself already blocks producing an oversized binary.

--

Two separate fixes, not one:

1. Trivial: app_storage.c's APP_MAX_SIZE check is redundant with the uint16_t field limit already enforced at build time — could be deleted in favor of the existing segment_size check.
2. Real fix: widening virtual_size/load_size to uint32_t is a breaking change to PebbleProcessInfo, documented as shared ABI with inject_metadata.py and iOS's PBBundle.m — a coordinated change, not a one-liner.

[truhanen]

Noticed a related discrepancy between the changelogs of PebbleOS & SDK.

PebbleOS changelog ~claims this issue has been fixed in v4.33.1:

SDK: emery/gabbro apps can now use the full 128 KB binary limit, was wrongly capped at 64 KB

SDK v4.33 changelog is a bit more honest:

The maximum app binary size on Emery and Gabbro is now 128 KiB (up from 64 KiB). The loaded image and RAM footprint are still limited to 64 KiB each; the extra room is available for relocation data.

Based on those, I think this issue is still relevant.