[lyakh]

UUID objects are represented by struct sof_uuid_entry instances in SOF. Instead of casting pointers to them to integers for passing around, carry them as pointers until they have to be cast to integers for packing into data structures. This also fixes printing UUID, using a "%pU" format.

with this patch, applied together with all other zephyr upstreaming patches, I can actually build zephyr+sof with no warnings

[lyakh]

Note: this PR applies cleanly but it won't build without #3376

[paulstelian97]

Can we have a custom attribute that tells us this is not a dereferenceable pointer? (for those that aren't)

[lyakh]

Can we have a custom attribute that tells us this is not a dereferenceable pointer? (for those that aren't)

@paulstelian97 sorry, which ones are you calling "not dereferenceable" and why do you think they are that?

[paulstelian97]

Can we have a custom attribute that tells us this is not a dereferenceable pointer? (for those that aren't)

@paulstelian97 sorry, which ones are you calling "not dereferenceable" and why do you think they are that?

Wait, all UUIDs are available in the .ri file and it's only traces themselves that have non-dereferenceable things in them?

[lyakh]

Can we have a custom attribute that tells us this is not a dereferenceable pointer? (for those that aren't)

@paulstelian97 sorry, which ones are you calling "not dereferenceable" and why do you think they are that?

Wait, all UUIDs are available in the .ri file and it's only traces themselves that have non-dereferenceable things in them?

@paulstelian97 as far as I understand in the firmware all the pointers are valid - both to format strings and to UUID objects. We just aren't sending them across to the kernel / the logger. Instead the logger looks up references into tables to retrieve format strings and UUIDs. So, in the logger those "pointers" cannot be dereferenced, but there they aren't really pointers either, they're 32-bit tokens. That's at least my current understanding, maybe I'm wrong.

[paulstelian97]

Can we have a custom attribute that tells us this is not a dereferenceable pointer? (for those that aren't)

@paulstelian97 sorry, which ones are you calling "not dereferenceable" and why do you think they are that?

Wait, all UUIDs are available in the .ri file and it's only traces themselves that have non-dereferenceable things in them?

@paulstelian97 as far as I understand in the firmware all the pointers are valid - both to format strings and to UUID objects. We just aren't sending them across to the kernel / the logger. Instead the logger looks up references into tables to retrieve format strings and UUIDs. So, in the logger those "pointers" cannot be dereferenced, but there they aren't really pointers either, they're 32-bit tokens. That's at least my current understanding, maybe I'm wrong.

From what I know, the format strings are stored in .ldc files and the firmware isn't allowed to actually dereference those pointers. The trace system only passes the pointer in the binary log format, and sof-logger does the actual (pseudo-)dereference to get to the format strings. If the firmware attempted to dereference the format strings, at least on the i.MX8QXP platform it would get bus errors (since 0x20000000 and similar isn't exactly a real address available on that specific platform; most interesting ones are above the 0x80000000 limit). So format strings are not dereferenceable.

I think at least initially some UUIDs were also like that, because UUIDs were originally only used for tracing. Again, the whole trace context isn't required on DSP so it's stored in the .ldc file for the logger to work with it.

[lyakh]

From what I know, the format strings are stored in .ldc files and the firmware isn't allowed to actually dereference those pointers. The trace system only passes the pointer in the binary log format, and sof-logger does the actual (pseudo-)dereference to get to the format strings. If the firmware attempted to dereference the format strings, at least on the i.MX8QXP platform it would get bus errors (since 0x20000000 and similar isn't exactly a real address available on that specific platform; most interesting ones are above the 0x80000000 limit). So format strings are not dereferenceable.

I think at least initially some UUIDs were also like that, because UUIDs were originally only used for tracing. Again, the whole trace context isn't required on DSP so it's stored in the .ldc file for the logger to work with it.

@paulstelian97 trace objects, created inside _log_message() using _DECLARE_LOG_ENTRY() are instantiated inside a special section, so, yes, accessing them might be... special. And in fact those structures aren't even accessible from outside of those macros except in the trace_log() function. So, that function could be declared something like

void trace_log(bool send_atomic, const void __trace *log_entry,
	       const struct tr_ctx *ctx, uint32_t lvl, uint32_t id_1,
	       uint32_t id_2, int arg_count, ...)

As for arguments of _log_message() I see no problem working with them in FW code.

As for UUIDs, yes, instances of struct sof_uuid_entry are in a separate section and we manipulate their pointers in FW code, so, yes, we could have an attribute for them too.

[lyakh]

SOFCI TEST

[lgirdwood]

Jenkins showing BSW DUT HW failure.