[BUG] logger "ABI" dictionary check ignores configuration and other changes

[marc-hb]

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.

[slawblauciak]

This issue most likely doesn't cause any functional problems.
However, it's to be checked if the CI logger issues are not caused by this.
@marc-hb can you check?

[marc-hb]

However, it's to be checked if the CI logger issues are not caused by this.

I don't remember using the logger before it had a "ABI check" but I assume using a wrong .ldc file was pretty bad otherwise no one would have spent so much effort implementing this ABI check in the first place. @ktrzcinx , others? Wrong log messages, logger crashes, others?

Now it can be:

• worse because the faulty ABI check will give a false sense of security and could distract the developer away from the root cause
• of course much better for developers who don't change their (K)config because they're not affected. How often do developers change their configuration?

Developers who automate the deployment of the .ldc file at the same time than the .ri firmware file are not affected either - but they were not affected before either and the ABI check did not solve a problem they had.

[marc-hb]

The simplest way to reproduce this issue (and most obvious with hindsight) is to use a firmware compiled with CONFIG_TRACEV and a .ldc dictionary file created without CONFIG_TRACEV. They have the same source checksum but the latter misses all tr_dbg() statements. In one attempt of doing so sof-logger -t fails with invalid text length and sof-logger without -t prints random garbage.

The converse surprisingly seems to work.

[marc-hb]

wontfix

[marc-hb]

COMP_BASEFW_IPC4 will also be ignored and cause a collision.

• ipc4: add get &set large config support #4808
• ASoC: SOF: IPC4 message abstraction and API change linux#3334

[marc-hb]

This git hash-object technique is also creating autocrlf issues:

• src/arch/xtensa: normalize two odd files from CRLF to LF #6920