GCC ARM: aligned access
Hi,
I am writing some code and found that system crashed. I found it was
unaligned access which causes `data abort` exception. I write a piece of code
and objdump
it. I am not sure this is right or not.
command:
arm-poky-linux-gnueabi-gcc -marm -mno-thumb-interwork -mabi=aapcs-linux
-mword-relocations -march=armv7-a -mno-unaligned-access -ffunction-sections
-fdata-sections -fno-common -ffixed-r9 -msoft-float -pipe -O2 -c 2.c -o 2.o
arch is armv7-a and used '-mno-unaligned access'
c code:
typedef unsigned char u8;
int func(u8 *data)
{
return *(unsigned int *)data;
}
The objdumped asm code is:
Disassembly of section .text.func:
:
0: e590 ldr r0, [r0]
4: e12fff1e bx lr
from the asm code, we can see that 'ldr r0, [r0]' corresponding to '*(unsigned
int*)data'. is this correct?
we can not guarantee that pointer data is 4bytes aligned. If pointer data is
not 4bytes aligned, and aligned
access check is enabled by setting a hardware bit in arm coprocessor, then
`data abort` may occur.
Regards,
Peng.
Ann: MELT 1.1.2 plugin for GCC 4.8 & 4.9 release (bugfixes)
Dear All,
It is my pleasure to announce the MELT 1.1.2 plugin for GCC 4.8 & 4.9.
MELT -see http://gcc-melt.org/ for more- is a domain specific language
to extend GCC, and a GCC plugin (free software, GPLv3 licensed, FSF
copyrighted).
This (mostly bug-fixing) release is available from
http://gcc-melt.org/melt-1.1.2-plugin-for-gcc-4.8-or-4.9.tar.bz2
as a bzip2-ed tar source file of md5sum
fab80bfaee76abea1513c69f504ab49f, and of 3936275 bytes (3.8 Megabytes),
extracted from MELT branch svn revision 214717. It brings bug fixes with
respect to MELT 1.1.1 (so you should upgrade).
Bug fixes
=
Better plugin build (ending message mention that probe is obsolete)
All passes data are cleared in hook_all_passes_end.
Gives an error message for unknown mode.
Reject loading twice the same MELT module.
register_pre_genericize_first & register_pre_genericize_last
should work.
mixbigint-s are understood by output_json.
assert_msg don't loop with non-value arguments.
do_blocking_jsonrpc2_call returns secondarily the time in
milliseconds needed to process the JSONRPC call.
register_gcc_attribute works, and is a macro.
tree_chain_to_tuple is a new function.
#
Please ask questions and give feedback (successes or bug reports) on
gcc-m...@googlegroups.com list.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
[wwwdocs] Patch for Re: _contribute.html_: missing information regarding feedback procedure
On Fri, 10 May 2013, Jonathan Wakely wrote: >> At the very bottom of the above page (http://gcc.gnu.org/contribute.html), >> there is no indication of GCC only accepting *plain text* messages. > That would belong on http://gcc.gnu.org/lists.html but it could be > improved, as it only says "Please refrain from sending messages in > HTML, RTF or similar formats." Good feedback. I just applied the clarification below which also makes some surrounding text a little bit shorter. Gerald Index: lists.html === RCS file: /cvs/gcc/wwwdocs/htdocs/lists.html,v retrieving revision 1.111 diff -u -r1.111 lists.html --- lists.html 1 Jul 2014 16:02:44 - 1.111 +++ lists.html 31 Aug 2014 16:31:11 - @@ -157,11 +157,11 @@ We have a strong policy of not editing the web archives. When posting messages, please select an appropriate list for the message -and try to avoid cross posting a message to several lists. +and try to avoid cross posting to several lists. -Please refrain from sending messages in HTML, RTF or similar formats. +Please send plain text (as opposed to HTML, RTF,...). -Please do not include or reference confidentiality +Do not include or reference confidentiality notices, like: The referring document contains privileged and confidential
Re: GCC ARM: aligned access
On August 31, 2014 8:19:49 AM CDT, Peng Fan wrote:
>Hi,
>
>I am writing some code and found that system crashed. I found it was
>unaligned access which causes `data abort` exception. I write a piece
>of code and objdump
>it. I am not sure this is right or not.
>
>command:
>arm-poky-linux-gnueabi-gcc -marm -mno-thumb-interwork -mabi=aapcs-linux
>-mword-relocations -march=armv7-a -mno-unaligned-access
>-ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float
>-pipe -O2 -c 2.c -o 2.o
>
>arch is armv7-a and used '-mno-unaligned access'
>
>c code:
>typedef unsigned char u8;
>
>int func(u8 *data)
>
>{
>
>return *(unsigned int *)data;
>
>}
>
>The objdumped asm code is:
>
>Disassembly of section .text.func:
>
>
> :
>
>0: e590 ldr r0, [r0]
>
> 4: e12fff1e bx lr
>
>from the asm code, we can see that 'ldr r0, [r0]' corresponding to
>'*(unsigned int*)data'. is this correct?
>we can not guarantee that pointer data is 4bytes aligned. If pointer
>data is not 4bytes aligned, and aligned
>access check is enabled by setting a hardware bit in arm coprocessor,
>then `data abort` may occur.
>
>
I think this is totally expected. You were passed a u8 pointer which is aligned
for that type (no restrictions likely). You cast it to a type with stricter
alignment requirements. The code is just flawed. Some CPUs handle unaligned
accesses but not your ARM.
If you turn on Wall, do you get a warning?
>Regards,
>Peng.
gcc-5-20140831 is now available
Snapshot gcc-5-20140831 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20140831/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 214771 You'll find: gcc-5-20140831.tar.bz2 Complete GCC MD5=87af5047c70ab4b31dba22a32d5a5da3 SHA1=d71c98f7ed517115d44655577d47ab2687be1b98 Diffs from 5-20140824 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
New anti-spam extension enabled on GCC Bugzilla
Hello, I just enabled an extension on GCC Bugzilla which automatically disables reporter's account if their bugs are marked as INVALID and are in the 'spam' component. So if you have enough privileges on GCC Bugzilla to close a bug as INVALID and to move it in the 'spam' component (in the 'gcc' product), you can help disabling these user accounts. It doesn't matter if the bug is closed as RESOLVED or CLOSED. What matters is the INVALID resolution. Note that you won't see any notification that the account has been disabled. That's expected. :) I re-enabled user account creation a few minutes ago, and already 2 new accounts have been created. Both are spammers. I have disabled them already. Note that my extension only disables reporters. It doesn't disable commenters who are also spammers (because we have no way to mark a comment as spam yet. This feature will come with Bugzilla 5.0). For them, admins will have to disable these accounts manually: https://gcc.gnu.org/bugzilla/editusers.cgi You type the email address of the user you want to find, then click on it and type some text in the "Disable text" field. You can also click the "Bugmail Disabled" checkbox to prevent the spammer from getting any new bugmail. Do not forget to click the "Save Changes" once you are done. Good luck! Frédéric PS: Do not hesitate to email me if there is something wrong with my extension.
Re: GCC ARM: aligned access
On Aug 31, 2014, at 11:32 AM, Joel Sherrill wrote: >> Hi, >> >> I am writing some code and found that system crashed. I found it was >> unaligned access which causes `data abort` exception. I write a piece >> of code and objdump >> it. I am not sure this is right or not. >> >> command: >> arm-poky-linux-gnueabi-gcc -marm -mno-thumb-interwork -mabi=aapcs-linux >> -mword-relocations -march=armv7-a -mno-unaligned-access >> -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float >> -pipe -O2 -c 2.c -o 2.o >> >> arch is armv7-a and used '-mno-unaligned access' > > I think this is totally expected. You were passed a u8 pointer which is > aligned for that type (no restrictions likely). You cast it to a type with > stricter alignment requirements. The code is just flawed. Some CPUs handle > unaligned accesses but not your ARM. While armv7 and armv6 supports unaligned access, that support has to be enabled by the underlying O/S. Not knowing the underlying environment, I can't say whether that support is enabled. One issue we had in NetBSD in moving to gcc4.8 was that the NetBSD/arm kernel didn't enable unaligned access for armv[67] CPUs. We quickly changed things so unaligned access is supported.
Re: GCC ARM: aligned access
On 09/01/2014 08:09 AM, Matt Thomas wrote:
>
> On Aug 31, 2014, at 11:32 AM, Joel Sherrill wrote:
>
>>> Hi,
>>>
>>> I am writing some code and found that system crashed. I found it was
>>> unaligned access which causes `data abort` exception. I write a piece
>>> of code and objdump
>>> it. I am not sure this is right or not.
>>>
>>> command:
>>> arm-poky-linux-gnueabi-gcc -marm -mno-thumb-interwork -mabi=aapcs-linux
>>> -mword-relocations -march=armv7-a -mno-unaligned-access
>>> -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float
>>> -pipe -O2 -c 2.c -o 2.o
>>>
>>> arch is armv7-a and used '-mno-unaligned access'
>>
>> I think this is totally expected. You were passed a u8 pointer which is
>> aligned for that type (no restrictions likely). You cast it to a type with
>> stricter alignment requirements. The code is just flawed. Some CPUs handle
>> unaligned accesses but not your ARM.
>
armv7 and armv6 arch except armv6-m support unaligned access. a u8 pointer is
casted to u32 pointer, should gcc take the align problem into consideration to
avoid possible errors? because -mno-unaligned-access.
> While armv7 and armv6 supports unaligned access, that support has to be
> enabled by the underlying O/S. Not knowing the underlying environment,
> I can't say whether that support is enabled. One issue we had in NetBSD
> in moving to gcc4.8 was that the NetBSD/arm kernel didn't enable unaligned
> access for armv[67] CPUs. We quickly changed things so unaligned access
> is supported.
Yeah. by set a hardware bit in arm coprocessor, unaligned access will not cause
data abort exception.
I just wonder is the following correct? should gcc take the responsibility to
take care possible unaligned pointer `u8 *data`? because -mno-unaligned-access
is passed to gcc.
int func(u8 *data)
{
return *(unsigned int *)data;
}
:
0: e590 ldr r0, [r0]
4: e12fff1e bx lr
Regards,
Peng.
>
Re: GCC ARM: aligned access
On Mon, Sep 01, 2014 at 09:14:31AM +0800, Peng Fan wrote:
>
>
> On 09/01/2014 08:09 AM, Matt Thomas wrote:
> >
> > On Aug 31, 2014, at 11:32 AM, Joel Sherrill
> > wrote:
> >
> >>> Hi,
> >>>
> >>> I am writing some code and found that system crashed. I found it was
> >>> unaligned access which causes `data abort` exception. I write a piece
> >>> of code and objdump
> >>> it. I am not sure this is right or not.
> >>>
> >>> command:
> >>> arm-poky-linux-gnueabi-gcc -marm -mno-thumb-interwork -mabi=aapcs-linux
> >>> -mword-relocations -march=armv7-a -mno-unaligned-access
> >>> -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float
> >>> -pipe -O2 -c 2.c -o 2.o
> >>>
> >>> arch is armv7-a and used '-mno-unaligned access'
> >>
> >> I think this is totally expected. You were passed a u8 pointer which is
> >> aligned for that type (no restrictions likely). You cast it to a type with
> >> stricter alignment requirements. The code is just flawed. Some CPUs handle
> >> unaligned accesses but not your ARM.
> >
> armv7 and armv6 arch except armv6-m support unaligned access. a u8 pointer is
> casted to u32 pointer, should gcc take the align problem into consideration
> to avoid possible errors? because -mno-unaligned-access.
> > While armv7 and armv6 supports unaligned access, that support has to be
> > enabled by the underlying O/S. Not knowing the underlying environment,
> > I can't say whether that support is enabled. One issue we had in NetBSD
> > in moving to gcc4.8 was that the NetBSD/arm kernel didn't enable unaligned
> > access for armv[67] CPUs. We quickly changed things so unaligned access
> > is supported.
>
> Yeah. by set a hardware bit in arm coprocessor, unaligned access will not
> cause data abort exception.
> I just wonder is the following correct? should gcc take the responsibility to
> take care possible unaligned pointer `u8 *data`? because
> -mno-unaligned-access is passed to gcc.
>
> int func(u8 *data)
>
> {
>
> return *(unsigned int *)data;
>
> }
I guess -mno-unaligned-access only applies to (potentially) unaligned addresses
that the compiler itself is aware of, like packed struct members.
Otherwise gcc would have to consider *every* memory load/store as
unaligned and break them down into byte loads/stores. In the above case,
you are telling the compiler that you know it is word aligned (by
casting), and the compiler believes you :).
Regards
Senthil
