Skip to content
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

cmake: add control over inline source code disassembly #71535

Merged
merged 1 commit into from
Apr 22, 2024

Conversation

LaurentiuM1234
Copy link
Collaborator

@LaurentiuM1234 LaurentiuM1234 commented Apr 16, 2024

By default, the generated disassembly file (i.e: the .lst file) also contains inline source code. This has the potential to become problematic when attempting to compare the generated .lst files accross platforms since they may differ for various reasons. As such, add the option to control whether the disassembly file should contain inline source code or not.

Relevant SOF issue: thesofproject/sof#9034

marc-hb
marc-hb previously approved these changes Apr 16, 2024
Copy link
Collaborator

@marc-hb marc-hb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, thank you!

@marc-hb
Copy link
Collaborator

marc-hb commented Apr 16, 2024

Relevant SOF issue: thesofproject/sof#9034

A bit more context in the commit message wouldn't hurt, maybe in the Kconfig help too.

At the least the keyword "reproducible build" would be great.

@LaurentiuM1234
Copy link
Collaborator Author

Relevant SOF issue: thesofproject/sof#9034

A bit more context in the commit message wouldn't hurt, maybe in the Kconfig help too.

At the least the keyword "reproducible build" would be great.

Updated. Not sure if explanation's good enough so lmk if it needs another update.

marc-hb
marc-hb previously approved these changes Apr 17, 2024
cfriedt
cfriedt previously approved these changes Apr 18, 2024
aescolar
aescolar previously approved these changes Apr 18, 2024
Kconfig.zephyr Outdated Show resolved Hide resolved
andyross
andyross previously approved these changes Apr 18, 2024
Copy link
Contributor

@andyross andyross left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense.

(Good opportunity for a general whine that the .lst file is now off by default. I'm constantly having to turn it back on and rebuild, and it wastes a minute or so for me almost every week. If CI can't handle the overhead we should have CI turn it off. Obviously not related to this PR, but while people's eyes are on this area...)

@marc-hb
Copy link
Collaborator

marc-hb commented Apr 18, 2024

Good opportunity for a general whine that the .lst file is now off by default.

I timed it and it was VERY slow, 7 seconds on my beefy build server! Also: not concurrent with anything else so frequently doubling the total build time! Not just for CI but for everybody. I think very few people look at zephyr.lst on a regular basis. More data in cc57633 / #61023 and thesofproject/sof@dd8b932

It will be interesting to measure it again without this -S. Linking source code to optimized code is really hard (and buggy as we just found) so maybe it was -S actually taking a lot of that time?

Assuming it can be very fast now without -S, having it on by default again but without -S would probably not be very useful to users like you either?

Default configuration is hard, really hard. You can never please all use cases. So the key is configuration flexibility and convenience with overlays etc. and I find Zephyr pretty good there.

I'm constantly having to turn it back on and rebuild, and it wastes a minute or so for me almost every week.

Can't you set this "permanently" in some personal overlay? Using west config build.cmake-args?

https://docs.zephyrproject.org/latest/develop/west/build-flash-debug.html#west-building-cmake-config

@marc-hb

This comment was marked as resolved.

@marc-hb marc-hb added the Hotfix Fix for issues blocking development, i.e. CI issues, tests failing in CI, etc. label Apr 18, 2024
iuliana-prodan
iuliana-prodan previously approved these changes Apr 19, 2024
@jori-nordic
Copy link
Collaborator

Good opportunity for a general whine that the .lst file is now off by default

I think I was the one turning it off.
As @marc-hb says it's single-threaded and was more than doubling the build time.

It doesn't matter for CI I guess, but for local development it sucks having to wait for objdump when you don't actually need it. I was certainly wasting more than a minute per week. It was more like 10-15s per-build and with 20+ builds every day it adds up.

I think having a default overlay that you apply for local development makes sense.

jori-nordic
jori-nordic previously approved these changes Apr 19, 2024
@marc-hb
Copy link
Collaborator

marc-hb commented Apr 19, 2024

It doesn't matter for CI I guess,

Zephyr CI builds hundreds of different configurations for each pull request, so CONFIG_OUTPUT_DISASSEMBLY does matter very much for it. Not just for time but for money too!

CONFIG_OUTPUT_DISASSEMBLY could be easily overriden in Zephyr CI if needed though (not needed since you disabled it by default)

@aescolar aescolar removed the Hotfix Fix for issues blocking development, i.e. CI issues, tests failing in CI, etc. label Apr 19, 2024
@aescolar
Copy link
Member

@marc-hb removing hotfix as this is not a critical Zephyr issue introduced by a regression (what hotfix should be used for).
@tejlmand can you please take a quick look?

Copy link
Collaborator

@tejlmand tejlmand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

code works, but would like to see the else() .. if() transformed into a cleaner elseif().

CMakeLists.txt Outdated
Comment on lines 1707 to 1709
else()
set(disassembly_type "$<TARGET_PROPERTY:bintools,disassembly_flag_inline_source>")
if (CONFIG_OUTPUT_DISASSEMBLE_WITH_SOURCE)
set(disassembly_type "$<TARGET_PROPERTY:bintools,disassembly_flag_inline_source>")
endif()
endif()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why the extra if() ?

Suggested change
else()
set(disassembly_type "$<TARGET_PROPERTY:bintools,disassembly_flag_inline_source>")
if (CONFIG_OUTPUT_DISASSEMBLE_WITH_SOURCE)
set(disassembly_type "$<TARGET_PROPERTY:bintools,disassembly_flag_inline_source>")
endif()
endif()
elseif (CONFIG_OUTPUT_DISASSEMBLE_WITH_SOURCE)
set(disassembly_type "$<TARGET_PROPERTY:bintools,disassembly_flag_inline_source>")
endif()

By default, the generated disassembly file (i.e: the .lst
file) also contains inline source code. This has the
potential to become problematic when attempting to compare
the generated .lst files accross platforms since they may
differ for various reasons. As such, add the option to
control whether the disassembly file should contain inline
source code or not.

The need for this patch was sparked by the differences
observed in the generated .lst file for Linux and Windows
in one of SOF's CI jobs (details in thesofproject/sof/issues/9034),
which were caused by the addition of the inline source code.
With this, we can keep testing for reproducible builds while
not having to deal with differences in the .lst files caused
by things such as having ".." include paths.

Signed-off-by: Laurentiu Mihalcea <[email protected]>
@LaurentiuM1234
Copy link
Collaborator Author

V2 changes

  1. Included @tejlmand and @aescolar's suggestions.

@carlescufi carlescufi merged commit fb7e937 into zephyrproject-rtos:main Apr 22, 2024
21 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.