-
Notifications
You must be signed in to change notification settings - Fork 349
zephyr: update print messages for 64-bit atomics #4975
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
Atomics will use `long` rather than `int` so that they are 64-bit on 64-bit builds and 32-bit on 32-bit builds. Required by zephyrproject-rtos/zephyr#39531 Signed-off-by: Christopher Friedt <[email protected]>
|
Can one of the admins verify this patch?
|
test this please |
|
Can one of the admins verify this patch? |
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.
shall we wait until the Zephyr PR is merged before merging this?
| tr_info(&ll_tr, "num_tasks %d total_num_tasks %d", | ||
| tr_info(&ll_tr, "num_tasks %ld total_num_tasks %ld", | ||
| atomic_read(&sch->num_tasks), | ||
| atomic_read(&domain->total_num_tasks)); |
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.
strictly speaking, this file isn't used with Zephyr so these changes aren't fixing Zephyr builds directly, but it's true, that we need consistency here. OTOH using %ld with 32-bit should actually generate warnings like
/tmp/p.c: In function ‘main’:
/tmp/p.c:8:19: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘int32_t’ {aka ‘int’} [-Wformat=]
8 | return printf("%ld\n", x);
| ~~^ ~
| | |
| | int32_t {aka int}
| long int
| %d
in XTOS builds but since we don't use __attribute__((__format__(printf,... ,...))) with XTOS builds (so far) we shouldn't be getting these. So, so far this should be safe...
The Zephyr fork is a downstream of this project, so the change needs to be merged here first, and then the Zephyr fork of sof needs to be updated, and then the west.yml ref needs to be updated in zephyrproject-rtos/zephyr#39531. I realize it's a bit confusing, but the idea is to preserve the upstream / downstream relationship and have coherent git history. Hopefully @nashif can clarify if above does not make sense. |
|
SOFCI TEST |
|
Rerun CI, looks like it got stuck. |
|
The zephyr build is expected to fail here. |
|
@lgirdwood done :) |
|
Follow-up in #5004 |
Atomics will use
longrather thanintso that they are 64-bit on 64-bit builds and 32-bit on 32-bit builds.Required by zephyrproject-rtos/zephyr#39531
Originally at zephyrproject-rtos#14
cc @lgirdwood @lyakh @kv2019i