While comparing various build outputs I realized "by chance" why using a source content hash for the logger ABI check (#3195)
is flawed. It's quite obvious with hindsight: that's simply because the "source" that git knows about is not the source code that gets compiled. git misses at least: pre-processing, generated config.h, compiler flags and version and maybe others.

These are the same reasons why ccache hashes much more than source code and even some compiler information:
https://ccache.dev/manual/4.2.html#_how_ccache_works

EDIT: the "most obvious" reproduction is with CONFIG_TRACEV, see below.

Sample reproductions as of latest commit f20b3ee:

• CONFIG_DEBUG changes the size of one of the .static.log.1 section in src/ipc/handler.c.o, which changes the .ldc file. Yet .ldc Source content hash does not change.

• CONFIG_OPTIMIZE_FOR_SIZE changes the size of one of the .static.log.1 section in src/audio/asrc/asrc_farrow.c.o which changes the .ldc file. Yet .ldc Source content hash does not change.

• CONFIG_FORMAT_S32LE changes the size of some .static.log.N sections in both src/audio/tdfb/tdfb.c.o and src/audio/eq_fir/eq_fir.c.o and probably others which changes the .ldc file. Yet .ldc Source content hash does not change.

Having an approximate .ldc check is probably better than none at all. However it misses most configuration changes right now and gives the wrong impression that everything is fine when the logger is actually broken.

I think the proper solution is to simply ask CMake to checksum the .ldc dictionary file itself because the dictionary is the thing and only thing that really matters here and then ask objcopy to inject the checksum into the final firmware file. This was already recommended in PR #3195 and rejected for confusing SMEX reasons.