ARMV6-M

ChibiOS public support forum for all topics not covered by a specific support forum.

Moderators: utzig, lbednarz, tfAteba, barthess, RoccoMarco

dflogeras
Posts: 190
Joined: Tue Sep 03, 2013 8:16 pm
Has thanked: 2 times
Been thanked: 13 times

ARMV6-M

Postby dflogeras » Tue Jan 29, 2019 1:12 pm

Hey Giovanni, thanks and congratulations on 19.x.y!

Reading through the release notes, I was wondering about the comment

Added a sanity check on GCC version for ARMv6-M, a version below 6 must be used.


Could you clarify the rationale for this?

Thanks
Dave

User avatar
Giovanni
Site Admin
Posts: 13020
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 748 times
Been thanked: 621 times
Contact:

Re: ARMV6-M

Postby Giovanni » Tue Jan 29, 2019 1:36 pm

There is a bug in GCC that impacts ChibiOS on Cortex-M0:

I reported it here:

https://bugs.launchpad.net/gcc-arm-embe ... ug/1803508

Then they reported it upstream here:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88167

The new ChibiOS version generates a warning if an impacted GCC is used.

Giovanni

mobyfab
Posts: 451
Joined: Sat Nov 19, 2011 6:47 pm
Location: Versailles, France
Has thanked: 12 times
Been thanked: 17 times

Re: ARMV6-M

Postby mobyfab » Thu Jan 31, 2019 3:24 pm

Is GCC 8 impacted as well?

User avatar
Giovanni
Site Admin
Posts: 13020
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 748 times
Been thanked: 621 times
Contact:

Re: ARMV6-M

Postby Giovanni » Thu Jan 31, 2019 3:31 pm

Everything starting from 6, the bug is acknowledged but not yet fixed.

It only affects M0/M0+, others are fine.

Giovanni

rew
Posts: 334
Joined: Sat Jul 19, 2014 12:59 pm
Been thanked: 9 times

Re: ARMV6-M

Postby rew » Thu Mar 21, 2019 10:08 am

Not sure why there are two threads about this. I wrote something about "good code" and workaround in the other thread. I think I did not explain clearly.

The proper way to write the code is apparently:

Code: Select all

 
__attribute__((used))
void *retaddr;

__attribute__((noinline))
void xxxxtest(void) {
  retaddr = __builtin_return_address(0);

  /* Used for enforcing registers stacking.*/
  asm volatile("" : : : "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7",
                        "r8", "r9", "r10", "r11", "r12");
}

The correctly compiled code would be something like:

Code: Select all

xxxxtest:
        push    {r4, r5, r6, r7, lr}
        mov     r4, fp
        mov     r7, r10
        mov     r6, r9
        mov     r5, r8
        mov     r2, lr
        ldr     r3, .L3
        push    {r4, r5, r6, r7}
        str     r2, [r3]
        pop     {r2, r3, r4, r5}
        mov     r8, r2
        mov     r9, r3
        mov     r10, r4
        mov     fp, r5
        pop     {r4, r5, r6, r7, pc}
(I probably removed too much of the non-code to make this work as-is).

I'm using r4 where the bad code is using "lr". r4 has already been pushed, but I'm not sure if I'm changing the order of stuff-on-the-stack this way so you will certainly have to double check my code.

Then as a workaround I propose:

Code: Select all

#ifdef COMPILER_BUG_PRESENT
#warning "Compiler bug present. Activating ugly workaround!"
asm ("xxxxtest:
        push    {r4, r5, r6, r7, lr}
        mov     r4, fp
        mov     r7, r10
        mov     r6, r9
        mov     r5, r8
        mov     r2, lr
        ldr     r3, .L3
        push    {r4, r5, r6, r7}
        str     r2, [r3]
        pop     {r2, r3, r4, r5}
        mov     r8, r2
        mov     r9, r3
        mov     r10, r4
        mov     fp, r5
        pop     {r4, r5, r6, r7, pc}");
 #else
 // On gcc versions 6 and up some optimization mis-compiles the following code. Above is the
 // hand-corrected version.
 __attribute__((used))
void *retaddr;

__attribute__((noinline))
void xxxxtest(void) {
  retaddr = __builtin_return_address(0);

  /* Used for enforcing registers stacking.*/
  asm volatile("" : : : "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7",
                        "r8", "r9", "r10", "r11", "r12");
 #endif



The reason I find this workaround important is that unless such a fix goes in, many people (like me) are restricted to sticking with a really old version of the compiler.

User avatar
Giovanni
Site Admin
Posts: 13020
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 748 times
Been thanked: 621 times
Contact:

Re: ARMV6-M

Postby Giovanni » Thu Mar 21, 2019 10:41 am

Hi,

There are several problems with that code:
- In your example retaddr is a static variable, any IRQ preempting another IRQ would overwrite it.
- I tried to add that register stacking enforcing to the current prologue macro, it uses an auto variable "_saved_lr", the problem is still there.

Code: Select all

#define PORT_IRQ_PROLOGUE()                                                 \
  regarm_t _saved_lr = (regarm_t)__builtin_return_address(0);               \
  asm volatile("" : : : "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7", "r8", "r9", "r10", "r11", "r12")

Code: Select all

 8005750:   b5f0         push   {r4, r5, r6, r7, lr}
 8005752:   46de         mov   lr, fp
 8005754:   4657         mov   r7, sl
 8005756:   464e         mov   r6, r9
 8005758:   4645         mov   r5, r8
 800575a:   4673         mov   r3, lr <---- HERE
 800575c:   b5e0         push   {r5, r6, r7, lr}

- Even if it worked, stacking all registers would worsen the IRQ performance.
- Even if it worked, it would be masking the problem not fixing it, there would be no guarantee it would work for all compiler versions, all possible options and all the possible ISR code following the fix.

The best solution I can see is to inform when a faulty compiler is used.

Giovanni

User avatar
Giovanni
Site Admin
Posts: 13020
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 748 times
Been thanked: 621 times
Contact:

Re: ARMV6-M

Postby Giovanni » Mon May 20, 2019 1:46 pm

Apparently the problem has been fixed in repository: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88167

Giovanni

dflogeras
Posts: 190
Joined: Tue Sep 03, 2013 8:16 pm
Has thanked: 2 times
Been thanked: 13 times

Re: ARMV6-M

Postby dflogeras » Mon Apr 20, 2020 9:20 pm

At least according to the release notes, all active branches of GCC now have been released with the fix, including:

7.5.0
8.4.0
9.3.0

User avatar
FXCoder
Posts: 277
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 112 times
Been thanked: 88 times

Re: ARMV6-M

Postby FXCoder » Tue Apr 21, 2020 12:28 am

Hi
See this post regarding status.
--
Bob


Return to “General Support”

Who is online

Users browsing this forum: No registered users and 5 guests