-
Notifications
You must be signed in to change notification settings - Fork 349
trace: avoid passing va_list #4574
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Passing va_list seems to result in issues with stopping the DMA. Call log_func() and mtrace_dict_entry() in the _log_message() macro instead to prevent this. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
|
SOFCI TEST |
to allow the build to succeed. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
lyakh
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll test this with Zephyr a bit later
| (lvl <= MTRACE_DUPLICATION_LEVEL ? \ | ||
| mtrace_dict_entry(true, (uint32_t)&log_entry, \ | ||
| META_COUNT_VARAGS_BEFORE_COMPILE(__VA_ARGS__), \ | ||
| ##__VA_ARGS__) : 0); \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ?: operator is (usually) used for returning a value. Do I understand it correctly that you just meant an if here? Also it would be nice to keep indentation for end-of-line backslashes
|
Lets try for this alternative before the revert as this still keeps the Zephyr trace working. @lyakh please report any Zephyr issues. |
plbossart
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have zero understanding of the relationships between the valist and APL build issues, and likewise why the use of the valist results in a DMA fail on CML only.
I would prefer a clean revert to this experiment-based approach where we really have no idea what we are doing. Nothing personal, I just feel like there is a different problem we haven't even root-cause behind all this.
| CONFIG_COMP_KPB=n | ||
| CONFIG_COMP_SEL=n | ||
| CONFIG_COMP_CROSSOVER=n | ||
| CONFIG_COMP_DRC=n |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A change to be va_list leads to a build failure?
Something's not right here...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@plbossart i've made the _log_message() macro heavier with this change and so it breaks the bss section for APL
| CONFIG_COMP_SRC_SMALL=y | ||
| CONFIG_COMP_TDFB=n | ||
| CONFIG_COMP_TONE=n | ||
| CONFIG_COMP_KPB=n |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
btw, we have a weird sof-apl-keyword-detect.m4 which presumably uses KPB on APL, although FWIW my brief test of that topology on UP2 wasn't very successful, so maybe it's broken anyway
I dont mind this @plbossart but your PR seems to show failures on 2 other devices that I dont see with mine. Can you please look into it? |
@lgirdwood I'm not able to decipher this failure. the function is defined in trace.c just as before except the signature is changed. I'm not sure why we're seeing this failure. Do you have any hints for me? |
The errors you are referring to are a completely unrelated failure on CML_SDW on trig-start. ADL has a similar issue. I've spent enough time on these firmware issues, my position is that we have to revert all of the CML issues. |
|
This actually looks like the correct fix (and aligns with Zephyr variadic tracing APIs) as I'm 99% sure now this is a compiler bug in the libgcc handling of the xtensa calling convention wrt to register and stack window spilling/shifting. e.g. the GCC va_list is typedef struct {
unsigned int gp_offset;
unsigned int fp_offset;
void *overflow_arg_area;
void *reg_save_area; <<< this will probably break as the registers may be shifted by 4, 8 or 12 in HW and the mapping could lose alignment
} va_list[1];XCC handles this as it has a better understanding of the window shifting/spilling and a different calling conventions ABI compared to GCC. The va_list definition in XCC may also have extra members to deal with windows spill/shift. |
|
@ranj063 are you able to rework this next week ? |
@lgirdwood yes, I can squash this with Marc's original commits and resubmit next week. |
|
closing for now. will resubmit next week |
Passing va_list seems to result in issues with stopping
the DMA. Call log_func() and mtrace_dict_entry() in the
_log_message() macro instead to prevent this.
This is an alternative for #4573 but needs to be tested with zephyr. Fixes the suspend/resume with capture issue on helios in my tests