[ECOS] vector.s branch 0 problem

Alexandre thekyz@gmail.com
Mon Jul 2 14:14:00 GMT 2007


Doesn't the call for "-Ttarget.ld" in the arm-elf-gcc command make the link ?

Those are the commands I use to compile my project under eclipse:

make INSTALL_DIR=/ecos-c/Projets/workspace/eCos-KernelBuild/IAR-LPC2106_install/
all
arm-elf-gcc -c -o boot.o
-I/ecos-c/Projets/workspace/eCos-KernelBuild/IAR-LPC2106_install//include
-Wa,-adhlns=boot.lst -mcpu=arm7tdmi -mno-short-load-words -Wall
-Wpointer-arith -Wstrict-prototypes -Winline -Wundef
-Woverloaded-virtual -g -O2 -ffunction-sections -fdata-sections
-fno-rtti -fno-exceptions -fvtable-gc -finit-priority boot.c
arm-elf-gcc -nostartfiles
-L/ecos-c/Projets/workspace/eCos-KernelBuild/IAR-LPC2106_install//lib
-Ttarget.ld -Wl,-Map=boot.map -mcpu=arm7tdmi -mno-short-load-words
-Wl,--gc-sections -Wl,-static -g -nostdlib -o boot boot.o
arm-elf-objdump -h -S -C boot.o > boot.lss

yet the boot.lss file I obtain as a result isn't by far resembling the
vectors.lss i spoke earlier.
Do i have to add a arm-elf-ld command after the arm-elf-gcc ones ?

On 7/2/07, Gary Thomas <gary@mlbassoc.com> wrote:
> -----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



More information about the Ecos-discuss mailing list