Hi Ken, All,

I like your approach of providing a minimalistic version of printf() for the logging purpose only.

This would benefit to code size and performance while rich print formatting has no practical needs in this project.

Best regards,

Anton

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: 27 December 2019 03:38
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [TF-M] The logging mechanism change in TF-M

Hi,

We met some issues while implementing logging APIs like printf:

• The build-in symbol optimization references other toolchain provided symbols into image (like change ‘printf’ to ‘puts’ or ‘xxxprintf’), this would happen in both we are implementing your ‘printf’ and referencing toolchain ‘printf’. Use a -fno-builtin would suppress this but this needs a compiler flag requirement for developers.
• If we don’t provide necessary symbol but somewhere in program referenced it, ARMCLANG would provide one for us which contains the semihosting things, this increases the code size and cause trouble while the device is not running under semihosting env.
• Also there are CMSIS user reports that __stdout would affect multiple thread object initialization. (No detail about the root cause, anyone could help provide something?)

So it would be better that we remove the reference to toolchain stdout APIs, this could simplify the logging implementation since firmware logging MAY not need rich format (Comments?). A customized printf-like API is provided for logging but not being named as ‘printf’ directly.

Due to the default logging device (UART) driver may be implemented for threads only, the logging functionality in exceptions is going to be suppressed for a while until we figure out how the logging in exceptions can be – there is a trade-off between security consideration (isolation) and performance (Routing the logging API to somewhere costs).

Please provide your thinking, or what kind of logging API you are using.

Thanks

/Ken