Thank you all for the reply and appreciate elaborate summary .
~Umesh
On Mon, May 18, 2015 at 10:08 PM, Richard Earnshaw
<richard.earns...@foss.arm.com> wrote:
> 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
>>>>
>>>
>
