Currently we take the address of a symbol as the interned log ID. This is good because it is guaranteed unique across the whole binary (that is the linker's job).
However, if you are combining multiple linked images together (e.g. using Hubris) the IDs are no longer unique.
We should add an optional feature which causes defmt to use the unique discriminator as the interned ID. This will make the log frames larger, but that's why it should be optional.
I think if you could add an optional unique identifier alongside the existing log id, (e.g. some build specific identifier) this would solve all the cases noted before.
multiple images have a way of identifying perhaps which images the message comes from
rebuilds could create unique image identifiers, e.g. based on a timestamp/hash.
Currently we take the address of a symbol as the interned log ID. This is good because it is guaranteed unique across the whole binary (that is the linker's job).
However, if you are combining multiple linked images together (e.g. using Hubris) the IDs are no longer unique.
We should add an optional feature which causes defmt to use the unique discriminator as the interned ID. This will make the log frames larger, but that's why it should be optional.