Hi Alain, >>> Creates a CONFIG_BT_DEBUG_FUNC_NAME option to include function names in >>> debug statements. >>> >>> Unlike other platforms __func__ isn't a string literal so it cannot be >>> automatically concatenated by the pre-processor. As a result, the >>> function name is passed as a parameter to the tracing function. Since >>> pr_debug is a function like macro, the normal expansion of BT_PREFIX_PARAM >>> does not work as it gets processed within the first parameter as well, >>> for this reason, BT_DBG is split into two versions. >>> >>> This patch was built tested with all 4 possible combinations of >>> CONFIG_BT_DEBUG_FUNC_NAME and CONFIG_BT_FEATURE_DEBUG configurations. >> >> can we please limit this to FEATURE_DEBUG since dynamic debug doesn’t need it. It can switch on function name debugging on a per debug statement. And even for FEATURE_DEBUG I would rather have it optional that can be enabled when needed via the experimental feature itself. > I agree on making this dependent on FEATURE_DEBUG as it may simplify > the configuration, but I don't think I like having this enabled via an > experimental feature as it complicates the tracing macros quite a bit > for no good reason. I don't see a scenario where someone would turn > on CONFIG_DEBUG_FUNC_NAME but not want it enabled. I left the Set Experimental Feature command flexible and so you could add an extra flags/settings bitmask additionally to choose how to format the debug strings. Similar to what dynamic debug is doing. An alternative is that you have two debug features, one for with function names and one without. If you turn on both, then the one with function names supersedes. Regards Marcel
