Sysprogs forums › Forums › VisualGDB › Warnings with Wall and Wextra
- This topic has 1 reply, 2 voices, and was last updated 3 weeks, 5 days ago by
support.
-
AuthorPosts
-
January 6, 2025 at 18:32 #36266
wtywtykk
ParticipantHi,
When I compile with -Wall and -Wextra, I get some warnings:
`1>C:\Users\wty\AppData\Local\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\STM32L4xxxx\StartupFiles\startup_stm32l432xx.c(579,5): warning : 'MemManage_Handler' specifies less restrictive attribute than its target 'Default_Handler': 'noreturn' 1> 580 | void MemManage_Handler() __attribute__ ((weak, alias ("Default_Handler"))); 1> | ^~~~~~~~~~~~~~~~~ 1>C:\Users\wty\AppData\Local\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\STM32L4xxxx\StartupFiles\startup_stm32l432xx.c(780,39): note : 'MemManage_Handler' target declared here 1> 780 | void __attribute__((naked, noreturn)) Default_Handler() 1> | ^~~~~~~~~~~~~~~ 1>C:\Users\wty\AppData\Local\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\STM32L4xxxx\StartupFiles\startup_stm32l432xx.c(578,5): warning : 'HardFault_Handler' specifies less restrictive attribute than its target 'Default_Handler': 'noreturn' 1> 579 | void HardFault_Handler() __attribute__ ((weak, alias ("Default_Handler"))); 1> | ^~~~~~~~~~~~~~~~~ 1>C:\Users\wty\AppData\Local\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\STM32L4xxxx\StartupFiles\startup_stm32l432xx.c(780,39): note : 'HardFault_Handler' target declared here 1> 780 | void __attribute__((naked, noreturn)) Default_Handler() 1> | ^~~~~~~~~~~~~~~`
`1>C:\Users\wty\AppData\Local\VisualGDB\EmbeddedEFPs\Profiler\InstrumentingProfiler.cpp(128): note : included from here 1>C:/Users/wty/AppData/Local/VisualGDB/EmbeddedEFPs/Profiler/SmallNumberCoder.h: In static member function 'static int SysprogsInstrumentingProfiler::SmallNumberCoder::IsSignedIntConstrained(int, int)': 1>C:\Users\wty\AppData\Local\VisualGDB\EmbeddedEFPs\Profiler\SmallNumberCoder.h(14,30): warning : left shift of negative value 1> 15 | int mask = -1 << bits; 1> | ~~~^~~~~~~ 1>C:/Users/wty/AppData/Local/VisualGDB/EmbeddedEFPs/Profiler/SmallNumberCoder.h: In static member function 'static int SysprogsInstrumentingProfiler::SmallNumberCoder::IsUnsignedIntConstrained(unsigned int, int)': 1>C:\Users\wty\AppData\Local\VisualGDB\EmbeddedEFPs\Profiler\SmallNumberCoder.h(21,30): warning : left shift of negative value 1> 22 | int mask = -1 << bits; 1> | ~~~^~~~~~~ 1>C:\Users\wty\AppData\Local\VisualGDB\EmbeddedEFPs\Profiler\InstrumentingProfiler.cpp(0): note : In function 'void SysprogsInstrumentingProfiler::SysprogsInstrumentingProfilerReturnHookImpl(void**)' 1>C:\Users\wty\AppData\Local\VisualGDB\EmbeddedEFPs\Profiler\InstrumentingProfiler.cpp(435,77): warning : unused variable 'holder' 1> 436 | VendorSpecificWorkarounds::VendorSpecificInterruptHolderRAII holder; 1> | ^~~~~~ 1>C:\Users\wty\AppData\Local\VisualGDB\EmbeddedEFPs\Profiler\InstrumentingProfiler.cpp(0): note : In function 'void SysprogsInstrumentingProfiler::SysprogsInstrumentingProfilerHookImpl(void**)' 1>C:\Users\wty\AppData\Local\VisualGDB\EmbeddedEFPs\Profiler\InstrumentingProfiler.cpp(481,77): warning : unused variable 'holder' 1> 482 | VendorSpecificWorkarounds::VendorSpecificInterruptHolderRAII holder; 1> | ^~~~~~ 1>C:\Users\wty\AppData\Local\VisualGDB\EmbeddedEFPs\Profiler\TestResourceManager.cpp(0): note : In function 'int _read(int, char*, int)' 1>C:\Users\wty\AppData\Local\VisualGDB\EmbeddedEFPs\Profiler\TestResourceManager.cpp(299,25): warning : unused parameter 'fd' 1> 300 | extern "C" int _read(int fd, char *pBuffer, int size) 1> | ~~~~^~`
I’m able to fix them either by modifing the files directly or by tweaking warning level for invdidual files. But it would be nice if you can fix them on your side.
Also is it possible to add something like “Dedicated warning and optimization level for BSP files”? Because somttimes there are warnings in BSP provided by chip manufacturers. And for some small devices we need to change optimization level for BSP files to fit all code into Flash in debug mode.
-
This topic was modified 3 weeks, 5 days ago by
support. Reason: formatting
January 16, 2025 at 17:36 #36289support
KeymasterHi,
Sorry for the delay, we were working on an updated package for the ARM toolchain.
The “noreturn” warning comes from the way interrupt handlers are defined in the release build. VisualGDB provides default “weak” implementations redirecting to Default_Handler(), while the DefaultHandler() itself is declared as noreturn to save a few bytes on prologue/epilogue. The redirected handlers are not declared as noreturn because some of them will be replaced by the user-provided implementations that do return. This saves a few bytes on optimizing away the default handler, but does produce warnings in the full warning mode.
This logic has been in place for about 10 years, so we are somewhat hesitant to change it, as it may break someone else’s workarounds or fixes. If you can find a good way to suppress the warnings with pragmas, you can submit a pull request modifying this file. If it doesn’t change any functionalities, and just disables particular warnings, we can propagate it to the upcoming BSP versions.
With profiler framework, you can submit a pull request here.
As for overriding the warning level, if you are using MSBuild, you can change it on the file level (select the files in Solution Explorer, open properties and change the build flags for just these files). For Advanced CMake, the BSP/profiler go into separate CMake targets, so you can manually add CMake-level statements to your CMakeLists.txt that would alter the build options for just these targets.
Edit: thanks for the pull request, we have merged it. Just one thing, the new SignExtend() version was introducing an extra conditional branch, that is slower than just series of bitwise instructions, so we reverted it to a modified version of the original one, that should address the warnings.
-
This reply was modified 9 hours, 44 minutes ago by
support. Reason: mentioned pull request
-
This topic was modified 3 weeks, 5 days ago by
-
AuthorPosts
- You must be logged in to reply to this topic.