Logging in a user-mode thread with 'no-optimization'

[cjwinklhofer]

When using the logging library in a user-mode thread, I get an MPU error when building with no-optimization. The CONFIG_NO_OPTIMIZATIONS=y implies CONFIG_LOG_ALWAYS_RUNTIME=y so the relevant part should be in:

include/zephyr/logging/log_msg.h

#if defined(CONFIG_LOG_ALWAYS_RUNTIME) || !defined(CONFIG_LOG)
#define Z_LOG_MSG_CREATE2(_try_0cpy, _mode,  _cstr_cnt, _domain_id, _source,\
			  _level, _data, _dlen, ...) \
do {\
	Z_LOG_MSG_STR_VAR(_fmt, ##__VA_ARGS__) \
	z_log_msg_runtime_create((_domain_id), (void *)(_source), \
				  (_level), (uint8_t *)(_data), (_dlen),\
				  Z_LOG_MSG_CBPRINTF_FLAGS(_cstr_cnt) | \
				  (IS_ENABLED(CONFIG_LOG_USE_TAGGED_ARGUMENTS) ? \
				   CBPRINTF_PACKAGE_ARGS_ARE_TAGGED : 0), \
				  Z_LOG_FMT_RUNTIME_ARGS(_fmt, ##__VA_ARGS__));\
	(_mode) = Z_LOG_MSG_MODE_RUNTIME; \
} while (false)
#else /* CONFIG_LOG_ALWAYS_RUNTIME || !CONFIG_LOG */

When I understand correctly, the z_log_msg_runtime_create should be a system-call to work properly from a user-mode thread?

So I tried to make a system-call instead (actually I added a new one that takes the composed string, instead of the var-args) - however, I noticed that already the access to '_source' results in an MPU violation when it is accessed in a user-thread. In case with CONFIG_NO_OPTIMIZATIONS=n the '_source' can be used without an MPU error. I think, with the optimization, the address of _source is directly passed to the system-call and therefore does not trigger the MPU error?

I am not sure, good chance that I mixed something up or could this be a general issue with logging, user-mode threads and no-optimization? Tested on a 'NUCLEO-U575ZI-Q' board.

Thanks
Christoph

[cjwinklhofer]

After doing some more analysis, I think that CONFIG_LOG_ALWAYS_RUNTIME=y does not work in a user-mode thread. In addition, when CONFIG_NO_OPTIMIZATIONS=n the logging module declarations (__log_current_data) are optimized out and the user-mode thread does not get a MPU violation.

I created a pull-request with a possible solution: #88269