Comment 8 for bug 1738730
Revision history for this message
| Murat Ursavas (murat-ursavas) wrote Re: Simple OR'ed assignment breaks the code silently | #8 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
demo site
(Get the code!)
John,
You're right. -fpack-struct option definitely changes the behavior for 6.3.1.
Here's enabled and disabled assembly output (got with 6 branch):
Enabled:
ldr r3, .L11+4
ldrb r2, [r3]
movs r2, #0
orr r2, r2, #1
strb r2, [r3]
ldrb r2, [r3, #1]
movs r2, #0
orr r2, r2, #4
strb r2, [r3, #1]
ldrb r2, [r3, #2]
movs r2, #0
strb r2, [r3, #2]
ldrb r2, [r3, #3]
movs r2, #0
strb r2, [r3, #3]
Disabled:
ldr r3, .L11+4
movw r2, #1025
str r2, [r3]
Looks like unaligned access is enabled for v7-m architecture by default.
One thing remains. OK, it has to access byte by byte to the packed struct members, but why with wrong values? This smells like a bug, isn't it?
[ After some short time ]
By the way, I've looked at the code again and looks like it has to set the register with correct values even with -fpacked-struct option. So why I'm seeing different values in the debug session? Let's say GDB reports wrong values, why the peripheral is not working as expected.
Note: I need packed structs for serializing communication and storage.