uaol-wov: Fix build issue related to MWW path, compiler options

[udaymb]

Fix the build issues related to

• libc.a path update to use from xt-clang xtensa
• comment ibuffer_allocater.cc entry as file does not exist
• Add zephyr compiler options
• Introduce assert_func

[lyakh]

we usually avoid committing commented out code. There are a coupe of exceptions around but they all should have good reasons

[udaymb]

@lyakh - acknowledged - removed the complete line

[lgirdwood]

Tested this on a pristine wcl-uaol-wov-002 west workspace with both toolchains (Zephyr SDK 1.0.1 and xt-clang RI-2022.10, core ace30_LX7HiFi4_PIF). The libc.a discovery fix is needed — without it wcl + xt-clang fails at configure with Microwakeword libc shim: libc.a not found for intel_ace30_ptl. Two findings though.

1. Dropping ibuffer_allocator.cc breaks the link on some tflite-micro trees

scripts/tensorflow-clone.sh pins tflite-micro e86d97b6, where IBufferAllocator is a header-only pure-virtual interface and the .cc genuinely does not exist — so the removal is correct there. But trees carrying the Xtensa ICF vtable-folding fix split those 13 virtuals out of line into ibuffer_allocator.cc, and on those the removal fails to link with ~14 undefined references, under both toolchains:

libmww_tflm_lib.a(micro_allocator.cc.obj):(.literal._ZN6tflite16IBufferAllocatorC2ERKS0_+0x0):
  undefined reference to `vtable for tflite::IBufferAllocator'
libmww_tflm_lib.a(persistent_arena_buffer_allocator.cc.obj):(.rodata._ZTVN6tflite30PersistentArenaBufferAllocatorE+0x18):
  undefined reference to `tflite::IBufferAllocator::AllocateTemp(unsigned int, unsigned int)'

Suggest guarding on the file's existence so both layouts build:

if(EXISTS "${TFLM_PATH}/tensorflow/lite/micro/arena_allocator/ibuffer_allocator.cc")
	target_sources(mww_tflm_lib PRIVATE
		${TFLM_PATH}/tensorflow/lite/micro/arena_allocator/ibuffer_allocator.cc)
endif()

Verified building both ways.

2. ptl still does not link (pre-existing, not caused by this PR)

With the above applied, wcl builds and signs, but ptl fails at zephyr_pre0.elf on the branch base and with this PR, under both toolchains:

libmww_libc_shim.a(libm_math_sf_exp.c.o): sf_exp.c:(.text.expf+0x12):
  dangerous relocation: call8: call target out of range: __addsf3

The shim ar x-es prebuilt members out of the toolchain's libc.a/libm.a. Those objects were compiled without -mlongcalls, so their calls to the libgcc soft-float helpers are plain CALL8 (±512 KB). Zephyr's Xtensa linker script places plain .text (libgcc) via *(.literal .text) at the front of the output section and per-function .text.* via the later *(.literal.* .text.*) rule at the back. On wcl, which still links, __addsf3 is at 0xa003504c and expf at 0xa0091450 — 378 KB apart. ptl's .text is 651 KB, so the ends fall out of range.

Renaming the extracted members' .text.<fn>/.literal.<fn> back to plain .text/.literal puts them in the same early cluster as libgcc (on ptl: expf 0xa00327bc, __addsf3 0xa0032d84, 1.5 KB apart). Longer term it would be better to build these few libm functions from source with the project's own flags rather than extracting foreign prebuilt objects.

Also worth noting

-mtext-section-literals is a real improvement and worth keeping. Measured worst-case l32r reach from the ld map (max text_end - literal_start over matching .literal.X/.text.X pairs): branch base under gcc needs 261,661 B against the 262,140 B limit — 479 bytes of margin, with 113 functions needing >224 KB. With the flag it drops to ~90 KB, zero functions over 224 KB.

Two caveats on scope: zephyr_compile_options(-mtext-section-literals) is global and reaches the Zephyr kernel, while -mlongcalls is added only to SOF INTERFACE; and neither reaches mww_tflm_lib, which is a plain add_library not on zephyr_interface.

Both fixes are on lgirdwood/sof:wcl-uaol-wov-002-build-fixes, based on this PR's head. With them, ptl and wcl both build under xt-clang, and the resulting sof-ptl.ri boots on PTL silicon (aphid): topology sof-ptl-dmic-wov-multi-4ch instantiates, DMIC ECNS capture records cleanly, and mtrace shows the full DMIC → ECNS → KPB → wov_arbiter → 3×(MFCC+MWW) chain running 16 TFLM inferences per slot with no firmware errors.

🤖 Generated with Claude Code