Re: [PATCH v3 10/14] perf cs-etm: Synthesize exception entries separately from branches

[Leo Yan <leo.yan@arm.com>]

Hi Ian,

On Thu, Nov 12, 2026 at 11:07:55PM -0800, Ian Rogers wrote:

[...]

> Hi Leo,
> 
> After commit 9648f9fc3525 ("perf cs-etm: Synthesize exception entries
> separately from branches") in perf-tools-next, perf's build-test
> (`make -C tools/perf O=/tmp/build CORESIGHT=1`, i.e. `make_with_coresight_O`)
> with GCC 15.2.0 (`gcc (Debian 15.2.0-14) 15.2.0`, `-O3`) fails with:
> 
>   In function ‘cs_etm__t32_instr_size’,
>       inlined from ‘cs_etm__instr_size’ at util/cs-etm.c:1390:10,
>       inlined from ‘cs_etm__copy_insn’ at util/cs-etm.c:1572:21:
>   util/cs-etm.c:1381:28: error: ‘instrBytes’ may be used uninitialized
>  [-Werror=maybe-uninitialized]
>    1381 |         return ((instrBytes[1] & 0xF8) >= 0xE8) ? 4 : 2;
>             |                  ~~~~~~~~~~^~~
>   util/cs-etm.c: In function ‘cs_etm__copy_insn’:
>   util/cs-etm.c:1372:12: note: ‘instrBytes’ declared here
>    1372 |         u8 instrBytes[2];
>             |            ^~~~~~~~~~
> 
> The uninitialized `instrBytes` in cs_etm__t32_instr_size() is actually
> pre-existing from commit a7ee4d625ede ("perf cs-etm: Support for ARM
> A32/T32 instruction sets in CoreSight trace"): cs_etm__frontend_mem_access()
> (via __cs_etm__mem_access()) can return 0 without writing to instrBytes
> when thread__find_map(), map__dso(), or dso__data_read_offset() fails.
> The changes around cs_etm__copy_insn() in this patch just shifted GCC's
> -O3 inlining enough for it to inline __cs_etm__mem_access() and spot the
> uninitialized read of instrBytes[1].
> 
> Zero-initializing `u8 instrBytes[2] = {};` (similar to instr16/instr32 in
> cs_etm__is_svc_instr()) or checking that cs_etm__frontend_mem_access() read
> ARRAY_SIZE(instrBytes) bytes before inspecting instrBytes[1] should fix it.

See the series to fix the issue:
https://lore.kernel.org/linux-perf-users/20261113-perf_fix_gcc15_failure-v1-0-eae592c5ff64@arm.com/T/#mcbc1b4ce7284c9575b273d504354ac733bcf39aa

Thanks for sharing the log and analysis.