On 18/05/15 17:18, Joey Ye wrote:
> In this case ldm is loading at alignment address. It is just loaded
> more than sizeof a. So it can be the bus that does not permit
> accessing memory beyond address range of a. Such a case I don't
> believe compiler is doing wrong.
>
If a starts on a 4-byte aligned boundary aligned and is 5 bytes long,
then a+7 must still be within the same word of memory as the last byte
of a (similarly for b). Neither of these addresses can fault, even if
they are beyond the end of the object itself. Anyway, such a fault
would be a segmentation fault, not a bus error.
R.
> On Mon, May 18, 2015 at 4:50 PM, Richard Earnshaw
> <richard.earns...@foss.arm.com> wrote:
>> On 18/05/15 10:05, Umesh Kalappa wrote:
>>> Hi All,
>>>
>>> Getting a bus/hard error for the below case ,make sense since ldm/stm
>>> expects the address to be word aligned .
>>>
>>> bash-4.1$ cat test.c
>>> struct test
>>> {
>>> char c;
>>> int i;
>>> } __attribute__((packed));
>>>
>>> struct test a,b;
>>>
>>> int main()
>>> {
>>> a =b ; //here compiler is not sure that a or b is word aligned
>>> return a.i;
>>> }
>>>
>>> bash-4.1$ arm-eabi-gcc -v
>>> Using built-in specs.
>>> COLLECT_GCC=arm-eabi-gcc
>>> COLLECT_LTO_WRAPPER=/nobackup/ukalappa/build/gcc/mv-ga/c4.7.0-p1/x86_64-linux/libexec/gcc/arm-eabi/4.7.0/lto-wrapper
>>> Target: arm-eabi
>>> Configured with: /nobackup/ukalappa/src/gcc/mv-ga/gcc/configure
>>> --srcdir=/nobackup/ukalappa/src/gcc/mv-ga/gcc --build=x86_64-linux
>>> --target=arm-eabi --host=x86_64-linux
>>> --prefix=/nobackup/ukalappa/build/gcc/mv-ga/c4.7.0-p1
>>> --exec-prefix=/nobackup/ukalappa/build/gcc/mv-ga/c4.7.0-p1/x86_64-linux
>>> --with-pkgversion='Cisco GCC c4.7.0-p1' --with-cisco-patch-level=1
>>> --with-cisco-patch-level-minor=0
>>> --with-bugurl=http://wwwin.cisco.com/it/services/
>>> --disable-maintainer-mode --enable-languages=c,c++ --disable-nls
>>> Thread model: single
>>> gcc version 4.7.0
>>>
>>> bash-4.1$ ./arm-eabi-gcc -march=armv7 -mthumb -S test.c
>>>
>>> bash-4.1$ cat test.s
>>> .syntax unified
>>> .arch armv7
>>> .fpu softvfp
>>> .eabi_attribute 20, 1
>>> .eabi_attribute 21, 1
>>> .eabi_attribute 23, 3
>>> .eabi_attribute 24, 1
>>> .eabi_attribute 25, 1
>>> .eabi_attribute 26, 1
>>> .eabi_attribute 30, 6
>>> .eabi_attribute 34, 1
>>> .eabi_attribute 18, 4
>>> .thumb
>>> .file "test.c"
>>> .comm a,5,4
>>> .comm b,5,4
>>
>> The above two lines create (common) instances of a and b that are 4-byte
>> aligned, so the LDM should not be faulting in this case, unless your
>> binutils have ignored the alignment constraints.
>>
>> I don't think the compiler has done the wrong thing here.
>>
>> R.
>>
>>> .text
>>> .align 2
>>> .global main
>>> .thumb
>>> .thumb_func
>>> .type main, %function
>>> main:
>>> @ args = 0, pretend = 0, frame = 0
>>> @ frame_needed = 1, uses_anonymous_args = 0
>>> @ link register save eliminated.
>>> push {r7}
>>> add r7, sp, #0
>>> movw r3, #:lower16:a
>>> movt r3, #:upper16:a
>>> movw r2, #:lower16:b
>>> movt r2, #:upper16:b
>>> ldmia r2, {r0, r1} //Bus error
>>> str r0, [r3]
>>> adds r3, r3, #4
>>> strb r1, [r3]
>>> movw r3, #:lower16:a
>>> movt r3, #:upper16:a
>>> ldr r3, [r3, #1] @ unaligned
>>> mov r0, r3
>>> mov sp, r7
>>> pop {r7}
>>> bx lr
>>> .size main, .-main
>>>
>>>
>>> Arm states that ldm/stm should be word aligned and generating ldm/stm
>>> in the above case is the compiler error/bug ,do you guys agree with me
>>> or i'm missing something here ?
>>>
>>>
>>> Thank you
>>> ~Umesh
>>>
>>
