-
Notifications
You must be signed in to change notification settings - Fork 89
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
Configure debug info to DWARF v4. #82
base: master
Are you sure you want to change the base?
Conversation
@Johnn333 could you apply the same dwarf flags to the LLVM PR and ensure they compile correctly? |
BTW, if you set the build mode to regular 'debug' you will also need these flags set:
|
37c52cc
to
479ab48
Compare
Looking at the docs it looks like However, the docs indicate that it was only introduced in CMake v3.11 and we need to support 3.6, so maybe we need to replace the |
479ab48
to
f8269af
Compare
This didn't work for me, perhaps because versions |
Seems okay on my end, it still compiles, full of warnings as ever. I'm hoping to spend some time at some point getting the GCC built libraries to be compatiable with LLD (currently Clang has to build all of CODAL and use those libraries), but with some of the changes to CODAL its much closer to being able to digest the default GCC ones. Wouldn't worry too much about the LLVM build :). |
f8269af
to
363e64d
Compare
c8d9b58
to
6e38ef8
Compare
The _INIT variables were introduced in CMake 3.11, and this project currently supports 3.6+. The CMAKE_<LANG>_FLAGS_<CONFIG> are reset here instead of using _INIT, as we want these to be the starting values, overwritting any CMake defaults. Debug info set to DWARF v4 because some tooling does not process v5 yet.
6e38ef8
to
fdc9faa
Compare
Okay, so essentially the Since we have to support older version of CMake anyway, I've replace With this change and comparing the before and after this patch, there are significant changes in the build. That's because until now we've been building with As a quick test, I've change the optimisation level on top of this patch to Before we can merge this PR with -Os, we should have a look at the affected components, as listed in lancaster-university/codal-microbit-v2#373 (comment) to see if anything that might be performance critical could be negatively affected. @JohnVidler could you have a look at the list there and confirm if we are relatively safe to introduce performance issues? |
As done by @thegecko in b0ab5ff.
This should also help with some of the issues I've seen with bloaty parsing DWARF v5 files produced by arm-none-eabi-gcc v12.3.