You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: