I just spent some time on this. It is a false alarm, and seems not related to #1900.
It only happens if I have optimizations enabled. On some builds it also happens on other functions than the aforementioned one. It is caused by R10 contents getting corrupted. Then I realized that I need to add the flag -ffixed-r10. (This is not mentioned in help of Kconfig, it only mentions that I have to add -finstrument-functions. Can someone who knows about this mechanism update the Kconfig help entry?) Adding the missing flag however, did not solve my issues. Code restarts at a point within __start, before OS initialization takes place. There is no apparent reason for the moment. I will try to track this down tomorrow. Στις Τετ, 7 Οκτ 2020 στις 2:03 μ.μ., ο/η David Sidrane < david.sidr...@nscdg.com> έγραψε: > Hi Fotis, > > > >NuttX is not able to boot at all with this option selected. I stepped > >through the code and it seems that nxsig_initialize actually causes a > stack > >overflow that is detected by the above check. > >Is this a bug, or I should configure something in a different way? > > Have you seen > > https://cwiki.apache.org/confluence/display/NUTTX/ARMv7-M+Run+Time+Stack+Checking > > We have this working in PX4. 'make px4_fmuv5_stackcheck' as of NuttX > master > a few weeks ago You can see it passing on the hardware test rack > > the last entry is px4_fmu-v5_stackcheck > > > http://ci.px4.io:8080/blue/organizations/jenkins/PX4_misc%2FFirmware-hardware/detail/master/2374/pipeline > > It is most likely a configuration and build issue. (Albet the SW stack > coloring is broken on master and under repair curretly) > > The __stack_overflow_trap should carry __attribute__ > ((no_instrument_function)) > > Also R10 has to be preserved. > > All files built in the build have to have the same CONFIG_ARMV7M_STACKCHECK > settings. > > The margin is artificially set. > > Are you using a separate interrupt stack? > > With a lot of the new changes, we can assume the init path's nesting level > has not been kept small. > > Increase the idle stack size by a lot (1024) and retest. > > > David > > -----Original Message----- > From: Fotis Panagiotopoulos [mailto:f.j.pa...@gmail.com] > Sent: Tuesday, October 06, 2020 12:40 PM > To: dev@nuttx.apache.org > Subject: Stack overflow during system init. > > Hi everyone, > > I just enabled CONFIG_ARMV7M_STACKCHECK, as I would like to have this > functionality in my project, but I am facing problems. > > NuttX is not able to boot at all with this option selected. I stepped > through the code and it seems that nxsig_initialize actually causes a stack > overflow that is detected by the above check. > Is this a bug, or I should configure something in a different way? > > Then I realized that __stack_overflow_trap is broken. > When a stack overflow happens, this function is called which is supposed to > cause a hardfault. However as __stack_overflow_trap is a function itself, > __cyg_profile_func_enter is called again. Once again it detects the > overflow and calls __stack_overflow_trap, and so on... > > Finally, as I see, the stack check is performed while entering a function, > which is wrong. If there is a stack overflow, it will be detected at the > next function call, which may be at a irrelevant part of the code. I > believe that the check shall be performed on the exit of a function, in > which case you will be sure that this specific function caused the > overflow. And of course it will solve the issue above with > __stack_overflow_trap. >
