bad memset implementation under certain conditions
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| GNU Arm Embedded Toolchain |
Undecided
|
Unassigned |
Bug Description
I tried upgrading from 9-2020-q2-update to 10-2020-q4-major and found that some devices running code compiled with the new version would lock up while others wouldn't.
After much debugging, I found that the hang occurs when memset() is called.
The devices that work have a memset that looks like this:
void * r0:4 <RETURN>
void * r0:4 s
int r1:4 c
size_t r2:4 n
size_t Stack[-0x10]:4 i XREF[4]: 08043702(W),
080436de 80 b4 push { r7 }
080436e0 89 b0 sub sp,#0x24
080436e2 00 af add r7,sp,#0x0
080436e4 f8 60 str s,[r7,#local_1c]
080436e6 b9 60 str c,[r7,#local_20]
080436e8 7a 60 str n,[r7,#local_24]
080436ea bb 68 ldr r3,[r7,#local_20]
080436ec 00 2b cmp r3,#0x0
080436ee 29 d1 bne LAB_08043744
080436f0 fb 68 ldr r3,[r7,#local_1c]
080436f2 03 f0 03 03 and r3,r3,#0x3
080436f6 00 2b cmp r3,#0x0
080436f8 24 d1 bne LAB_08043744
080436fa fb 68 ldr r3,[r7,#local_1c]
080436fc fb 61 str r3,[r7,#s32]
080436fe 7b 68 ldr r3,[r7,#local_24]
08043700 9b 08 lsr r3,r3,#0x2
08043702 bb 61 str r3,[r7,#i]
08043704 07 e0 b LAB_08043716
08043706 fb 69 ldr r3,[r7,#s32]
08043708 1a 1d add n,r3,#0x4
0804370a fa 61 str n,[r7,#s32]
0804370c 00 22 mov n,#0x0
0804370e 1a 60 str n,[r3,#0x0]
08043710 bb 69 ldr r3,[r7,#i]
08043712 01 3b sub r3,#0x1
08043714 bb 61 str r3,[r7,#i]
08043716 bb 69 ldr r3,[r7,#i]
08043718 00 2b cmp r3,#0x0
0804371a f4 d1 bne LAB_08043706
0804371c 7b 68 ldr r3,[r7,#local_24]
0804371e 03 f0 02 03 and r3,r3,#0x2
08043722 00 2b cmp r3,#0x0
08043724 05 d0 beq LAB_08043732
08043726 fb 69 ldr r3,[r7,#s32]
08043728 00 22 mov n,#0x0
0804372a 1a 80 strh n,[r3,#0x0]
0804372c fb 69 ldr r3,[r7,#s32]
0804372e 02 33 add r3,#0x2
08043730 fb 61 str r3,[r7,#s32]
08043732 7b 68 ldr r3,[r7,#local_24]
08043734 03 f0 01 03 and r3,r3,#0x1
08043738 00 2b cmp r3,#0x0
0804373a 13 d0 beq LAB_08043764
0804373c fb 69 ldr r3,[r7,#s32]
0804373e 00 22 mov n,#0x0
08043740 1a 70 strb n,[r3,#0x0]
08043742 0f e0 b LAB_08043764
08043744 fb 68 ldr r3,[r7,#local_1c]
08043746 7b 61 str r3,[r7,#s2]
08043748 08 e0 b LAB_0804375c
0804374a 7b 69 ldr r3,[r7,#s2]
0804374c 5a 1c add n,r3,#0x1
0804374e 7a 61 str n,[r7,#s2]
08043750 ba 68 ldr n,[r7,#local_20]
08043752 d2 b2 uxtb n,n
08043754 1a 70 strb n,[r3,#0x0]
08043756 7b 68 ldr r3,[r7,#local_24]
08043758 01 3b sub r3,#0x1
0804375a 7b 60 str r3,[r7,#local_24]
0804375c 7b 68 ldr r3,[r7,#local_24]
0804375e 00 2b cmp r3,#0x0
08043760 f3 d1 bne LAB_0804374a
08043762 00 e0 b LAB_08043766
08043764 00 bf nop
08043766 fb 68 ldr r3,[r7,#local_1c]
08043768 18 46 mov s,r3
0804376a 24 37 add r7,#0x24
0804376c bd 46 mov sp,r7
0804376e 5d f8 04 7b pop.w r7=>local_4
08043772 70 47 bx lr
The memset that hangs looks like this:
void * r0:4 <RETURN>
void * r0:4 __s
int r1:4 __c
size_t r2:4 __n
08017f98 2d e9 f0 41 push { r4, r5, r6, r7, r8, lr }
08017f9c 00 f0 03 07 and r7,__s,#0x3
08017fa0 0f 43 orr r7,__c
08017fa2 05 46 mov r5,__s
08017fa4 14 46 mov r4,__n
08017fa6 06 d0 beq LAB_08017fb6
08017fa8 04 44 add r4,__s
08017faa 03 46 mov r3,__s
08017fac a3 42 cmp r3,r4
08017fae 15 d0 beq LAB_08017fdc
08017fb0 03 f8 01 1b strb.w __c,[r3],#0x1
08017fb4 fa e7 b LAB_08017fac
08017fb6 22 f0 03 06 bic r6,__n,#0x3
08017fba 4f ea 92 08 lsr.w r8,__n,#0x2
08017fbe 39 46 mov __c,r7
08017fc0 32 46 mov __n,r6
08017fc2 ff f7 e9 ff bl memset void * memset(void * __s, int __
08017fc6 a1 07 lsl __c,r4,#0x1e
08017fc8 05 eb 06 02 add.w __n,r5,r6
08017fcc 44 bf itT mi
08017fce 25 f8 28 70 strh.mi.w r7,[r5,r8,lsl #0x2]
08017fd2 02 32 add.mi __n,#0x2
08017fd4 e3 07 lsl r3,r4,#0x1f
08017fd6 01 d5 bpl LAB_08017fdc
08017fd8 00 23 mov r3,#0x0
08017fda 13 70 strb r3,[__n,#0x0]
08017fdc 28 46 mov __s,r5
08017fde bd e8 f0 81 pop.w { r4, r5, r6, r7, r8, pc }
The one that locks up recursively calls memset() which I assume is leading to an infinite loop.
All devices are use the same compiler options so I don't know why they would get a different memset implementation.
stewo (wolfer-y) wrote : [Autoreply] [Bug 1910469] [NEW] bad memset implementation under certain conditions | #1 |
David Lechner (dlech) wrote : | #2 |
After more research, it looks like this is the issue: https:/
So probably not a bug in GCC.
Changed in gcc-arm-embedded: | |
status: | New → Invalid |
stewo (wolfer-y) wrote : [Autoreply] [Bug 1910469] Re: bad memset implementation under certain conditions | #3 |
Ich bin bis 11.01. nicht im Haus und kann Ihre Nachricht daher leider nicht bearbeiten. In dringenden Fällen wenden Sie sich bitte an <email address hidden> bzw. für technische Fragen an <email address hidden>.
I am out of office until January 11th and won't be able to read your message. In urgent cases, please refer to <email address hidden> or for technical questions to <email address hidden>.
Mit freundlichen Grüßen / Best regards
Steffen Wolfer
--
Dipl.-Inform. Steffen Wolfer
Software Engineer Embedded Systems
WEISS ROBOTICS GmbH & Co. KG
Karl-Heinrich-
D-71640 Ludwigsburg, Germany
Phone: +49 7141 94702-22
Fax: +49 7141 94702-99
http://
Sitz der Gesellschaft: Ludwigsburg
Registergericht Stuttgart, HRA725006
Pers. haftende Gesellschafterin:
Weiss Robotics Verwaltungs-GmbH, Sitz Ludwigsburg
Registergericht Stuttgart, HRB73310
Geschäftsführer: Dr. Karsten Weiß
After more research, it looks like this is the issue:
https:/
So probably not a bug in GCC.
** Bug watch added: github.
https:/
** Changed in: gcc-arm-embedded
Status: New => Invalid
--
You received this bug notification because you are subscribed to GNU Arm
Embedded Toolchain.
Matching subscriptions: Älles
https:/
Title:
bad memset implementation under certain conditions
Status in GNU Arm Embedded Toolchain:
Invalid
Bug description:
I tried upgrading from 9-2020-q2-update to 10-2020-q4-major and found
that some devices running code compiled with the new version would
lock up while others wouldn't.
After much debugging, I found that the hang occurs when memset() is
called.
The devices that work have a memset that looks like this:
void * r0:4 <RETURN>
void * r0:4 s
int r1:4 c
Ich bin bis 11.01. nicht im Haus und kann Ihre Nachricht daher leider nicht bearbeiten. In dringenden Fällen wenden Sie sich bitte an <email address hidden> bzw. für technische Fragen an <email address hidden>.
I am out of office until January 11th and won't be able to read your message. In urgent cases, please refer to <email address hidden> or for technical questions to <email address hidden>.
Mit freundlichen Grüßen / Best regards
Steffen Wolfer
--
Dipl.-Inform. Steffen Wolfer
Software Engineer Embedded Systems
WEISS ROBOTICS GmbH & Co. KG Käferle- Str. 8
Karl-Heinrich-
D-71640 Ludwigsburg, Germany
Phone: +49 7141 94702-22 www.weiss- robotics. com
Fax: +49 7141 94702-99
http://
Sitz der Gesellschaft: Ludwigsburg
Registergericht Stuttgart, HRA725006
Pers. haftende Gesellschafterin:
Weiss Robotics Verwaltungs-GmbH, Sitz Ludwigsburg
Registergericht Stuttgart, HRB73310
Geschäftsführer: Dr. Karsten Weiß
Public bug reported:
I tried upgrading from 9-2020-q2-update to 10-2020-q4-major and found
that some devices running code compiled with the new version would lock
up while others wouldn't.
After much debugging, I found that the hang occurs when memset() is
called.
The devices that work have a memset that looks like this:
void * r0:4 <RETURN>
void * r0:4 s
int r1:4 c
size_t r2:4 n
size_t Stack[-0x10]:4 i XREF[4]: 08043702(W),