Page 4 of 5

Re: strange behavior of the scheduler on STM32F070

Posted: Tue Nov 27, 2018 10:48 pm
by apmorton
Obviously a compiler fix is the best solution, but having gone down this path before with regressions in gcc-arm-none-eabi I would not hold my breath. I am still waiting on some regressions reported and confirmed over a year ago.

A less than great workaround might be to mark the IRQ handler as

Code: Select all

__attribute__((naked))


If you aren't familiar with the attribute, it is mentioned here: https://gcc.gnu.org/onlinedocs/gcc/ARM- ... Attributes

Strictly speaking you can only rely on plain asm statements inside a naked function, so to be on the safe side you would need to declare a separate function that *isn't* naked and move the current function body there - excluding the lr save/restore macros. You can then use inline assembly in the naked function to call your new/real IRQ handler.

If it works it's not the worst hack in the world, and it's better than #error with a bugged compiler version.

Re: strange behavior of the scheduler on STM32F070

Posted: Sat Feb 02, 2019 6:33 pm
by gclarkii
Also available is to mark the function as
int __attribute__((optimize("O0"))) foo(uint8_t fooin) {
}
OR
#pragma GCC push_options
#pragma GCC optimize ("O0")
CODE
#pragma GCC pop_options

Just a couple of more options

Oh, Giovanni, where is that code for the cortex-M0 located? I'll modify the code to include one of the above and see if my locks still persist.

Never mind, I found the correct file and modified the code as follows:

Code: Select all

#pragma GCC push_options
#pragma GCC optimize ("O0")
#if defined(__GNUC__) || defined(__DOXYGEN__)
#define PORT_IRQ_PROLOGUE()                                                 \
  regarm_t _saved_lr = (regarm_t)__builtin_return_address(0)
#elif defined(__ICCARM__)
#define PORT_IRQ_PROLOGUE()                                                 \
  regarm_t _saved_lr = (regarm_t)__get_LR()
#elif defined(__CC_ARM)
#define PORT_IRQ_PROLOGUE()                                                 \
  regarm_t _saved_lr = (regarm_t)__return_address()
#endif
#pragma GCC pop_options


With that modification, compiling with -O2 and 230400 I've experienced ZERO locks! :mrgreen:
In over 20,000 cycles!

So the locks on the STM32F030K6/F4 were due to the bug. Still does not explain why the 030CC ran just fine...Arrggghhhh
Giovanni, do you see any down sides to O0 for just that code? It requires no other changes that I can see.

GB

Re: strange behavior of the scheduler on STM32F070

Posted: Sat Feb 02, 2019 6:52 pm
by Giovanni
Hi,

The code is located under /os/common/ports/ARMCMx/compilers/chcore_v6m.c

I am familiar with the naked attribute, you would have to do full stacking even for those ISRs not needing it. Removing optimizations is not an option for the same reason, performance. This is also a commercial product anything less than a full solution is not an option.

This is why I am deprecating the faulty compilers.

Giovanni

Re: strange behavior of the scheduler on STM32F070

Posted: Sat Feb 02, 2019 7:18 pm
by gclarkii
How much of slow down is it really?

Looking the original report of the bug, 5 lines of assembly are added for the O0 level. I don't have clue how that would translate in performance though.

Maybe make it an option via make. I'm willing to bet that the vast majority of people, including the commercial customers, would rather use a new GCC and take the hit. Also, how many of the commercial customers are even running GCC compared to the other compilers?

Turn it off by default and just document it in the demo files for the M0/M0+.

Re: strange behavior of the scheduler on STM32F070

Posted: Sat Feb 02, 2019 7:23 pm
by Giovanni
That code is in one of the most critical places and affects interrupts handling.

Giovanni

Re: strange behavior of the scheduler on STM32F070

Posted: Sat Feb 02, 2019 7:33 pm
by gclarkii
If nothing else, make sure that the bug is noted(Maybe in each demo file/makefile or ???) and how to work around it, both ways.
i.e. use an older GCC or modify the code as follows and note the performance hit. I'm not using ChibiOS as a RTOS, but as a VERY good foundation.
In the areas where I need the performance I'm using M3/M4 cores anyway.

Code: Select all

#if defined(__GNUC__) || defined(__DOXYGEN__)
#pragma GCC push_options
#pragma GCC optimize ("O0")
#define PORT_IRQ_PROLOGUE()                                                 \
  regarm_t _saved_lr = (regarm_t)__builtin_return_address(0)
  #pragma GCC pop_options
#elif defined(__ICCARM__)
#define PORT_IRQ_PROLOGUE()                                                 \
  regarm_t _saved_lr = (regarm_t)__get_LR()
#elif defined(__CC_ARM)
#define PORT_IRQ_PROLOGUE()                                                 \
  regarm_t _saved_lr = (regarm_t)__return_address()
#endif


Ok, I'll shut up now. I just felt that people should be given the choices.... :geek:
(Also confirming to limited degree that the above fixes my problem. There might be side effects that I just don't hit)

Re: strange behavior of the scheduler on STM32F070

Posted: Wed Jul 24, 2019 9:13 am
by steved
Looks like optimisation problems aren't confined to the M0 core. I've just spent some time chasing a problem on F767 code which again turns out to be an optimisation problem in GCC 7. Not looked in detail, but I suspect an intermediate calculation mis-optimised in some way.
Using optimisation level -Og the code works with GCC V5.4; not with V6.3 or V7.2.1
Have reverted to -O0 for now - adds about 20% to code size

Re: strange behavior of the scheduler on STM32F070

Posted: Wed Jul 24, 2019 5:55 pm
by Giovanni
This must be another problem, that one was M0-specific. Have you tried the latest Q3 GCC release?

It would be a good thing to identify the problem, do you have a general idea of what is failing?

Giovanni

Re: strange behavior of the scheduler on STM32F070

Posted: Wed Jul 24, 2019 9:12 pm
by steved
Haven't really looked into the problem yet; needed some properly working code about three weeks ago!

Will try and look further once the dust has settled; but could be fun because most likely the failing code is in a third party library (although I do have the source).

Note that I've not tried GCC8 at all yet.

Re: strange behavior of the scheduler on STM32F070

Posted: Fri Aug 09, 2019 10:46 am
by steved
Just tried GCC 8.3.1, Chibi 19.1.3 with no change - problems if -Og enabled.
Also had problems with static objects on Chibi 19.1.3 - separate topic if I can work out what's happening.