Re: [ECOS] vector.s branch 0 problem

[Gary Thomas <gary at mlbassoc dot com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexandre wrote:
> Hi everyone,
> 
> I may have a found why my ecos does not work at all but i'd like so
> feedback on it.
> I used the command:
> arm-elf-objdump -h -S -C vectors.o > vectors.lss
> to have a clearer view of what was going on at the init scale.
> Everything seemed nice so far but this morning i noticed that on the
> rom vectors init:
> 
> Disassembly of section .vectors:
> 
> 00000000 <__exception_handlers>:
>   0:    eafffffe     b    0 <__exception_handlers>
>   4:    e59ff018     ldr    pc, [pc, #24]    ; 24 <.undefined_instruction>
>   8:    e59ff018     ldr    pc, [pc, #24]    ; 28 <.software_interrupt>
>   c:    e59ff018     ldr    pc, [pc, #24]    ; 2c <.abort_prefetch>
>  10:    e59ff018     ldr    pc, [pc, #24]    ; 30 <.abort_data>
>  14:    b4405f62     strltb    r5, [r0], -#3938
>  18:    e59ff018     ldr    pc, [pc, #24]    ; 38 <.IRQ>
>  1c:    e59ff018     ldr    pc, [pc, #24]    ; 3c <.FIQ>
> 
> I'm not a real genius when it come to assembly language but seems to
> me the thing just loops forever at address 0.
> 
> I lurked a bit into vector.s and found the code that generated the
> part above was that:
> 
>        .global __exception_handlers
> __exception_handlers:
> #ifdef CYGSEM_HAL_ROM_RESET_USES_JUMP
> // Assumption:  ROM code has these vectors at the hardware reset address.
> // A simple jump removes any address-space dependencies [i.e. safer]
>        b       reset_vector                    // 0x00
> #else
>        ldr     pc,.reset_vector                // 0x00
> #endif
>        ldr     pc,.undefined_instruction       // 0x04
>        ldr     pc,.software_interrupt          // 0x08 start && software
> int
>        ldr     pc,.abort_prefetch              // 0x0C
>        ldr     pc,.abort_data                  // 0x10
> #ifdef CYGNUM_HAL_ARM_VECTOR_0x14
>        .word   CYGNUM_HAL_ARM_VECTOR_0x14
> #else
>        .word   0                               // unused
> #endif
>        ldr     pc,.IRQ                         // 0x18
>        ldr     pc,.FIQ                         // 0x1C
> 
> Now if we take a closer look at the code at 0, it is supposed to
> branch to the start of the reset_vector. I noticed there's isn't a "."
> (dot) at the start of the name, don't know if it's important or not
> but as those are right from the cvs i thought it would be improper to
> change it.
> 
> Do you guys have any idea what comes wrong here ?

You're looking at "vectors.o", correct?  This doesn't work
because the instruction you are looking at needs some additional
"relocation" - in particular the address of 'reset_vector' - to
be added into it.   This is done by the linker (arm-elf-ld).

Try looking at the same piece of code in the final ELF
image and you'll see that it's quite different.



- --
- ------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGiQEEmaKbSsQGV8ARAgLjAJ0XLNz/FsExrFv8wSEmzIQSHsYf9ACbBbHu
GtlH2mWpqXMlXAgyO/+QaNo=
=9f+r
-----END PGP SIGNATURE-----

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss