This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Problem with arm-elf -> arm-a.out objcopy




On Wed, 31 Oct 2001, Jason R Thorpe wrote:

> Folks...

I was grapling with various arm-aout issues a few weeks before,
I found that, arm-elf and arm-aout are two vey different versions.
while arm-elf is being actively devloped and supported, arm-aout
is left at the level allowing work with gnu-2.8/apcs-26 configurations.


>
> I'm having a problem with arm-elf -> arm-a.out objcopy in
> binutils 2.11.2.
>
> First, some context.  I have a machine who's firmware only swallows
> a.out executables.  We need to use an ELF toolchain on the platform
> (for all the reasons one likes to use ELF), but I have to convert
> whatever the firmware loads (either a bootloader or the kernel itself)
> into a.out.

IMHO, write a small utility which will fix aout headers the way you feel
appropriate.

Thanks,

Aleksey

>
> This is what objdump tells me about a kernel image built with the
> a.out toolchain I'm trying to get away from (this toolchain is
> sufficiently old that it can't generate arm-elf):
>
> /users/thorpej/netbsd.arm-aout:     file format a.out-arm-netbsd
> /users/thorpej/netbsd.arm-aout
> architecture: arm, flags 0x000001be:
> EXEC_P, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS, WP_TEXT, D_PAGED
> start address 0xf0000020
>
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         00193fe0  f0000020  f0000020  00000020  2**2
>                   CONTENTS, ALLOC, LOAD, CODE
>   1 .data         00008000  f0194000  f0194000  00194000  2**2
>                   CONTENTS, ALLOC, LOAD, DATA
>   2 .bss          0002b398  f019c000  f019c000  00000000  2**2
>                   ALLOC
>
> Note the image is a ZMAGIC -- and the a.out loader in the system's
> firmware does the traditional thing with ZMAGIC -- loads the a.out
> header along with the .text section, hence a start address corresponding
> to the file offset of .text.
>
> Now, here is the objdump of an image build w/ gcc 2.95.3 and binutils
> 2.11.2 targeted at arm-unknown-netbsdelf:
>
> netbsd:     file format elf32-littlearm
> netbsd
> architecture: arm, flags 0x00000112:
> EXEC_P, HAS_SYMS, D_PAGED
> start address 0xf0000000
>
> Program Header:
>     LOAD off    0x00008000 vaddr 0xf0000000 paddr 0xf0000000 align 2**15
>          filesz 0x0015c188 memsz 0x0015c188 flags r-x
>     LOAD off    0x00164188 vaddr 0xf0164188 paddr 0xf0164188 align 2**15
>          filesz 0x00006b44 memsz 0x0002bde8 flags rw-
> private flags = 2: [APCS-32] [has entry point]
>
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         0015c188  f0000000  f0000000  00008000  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   1 .data         00006b44  f0164188  f0164188  00164188  2**2
>                   CONTENTS, ALLOC, LOAD, DATA
>   2 .sbss         00000000  f016accc  f016accc  0016acd0  2**0
>                   CONTENTS
>   3 .bss          000252a0  f016acd0  f016acd0  0016acd0  2**4
>                   ALLOC
>   4 .ident        00000501  00000000  00000000  0016acd0  2**0
>                   CONTENTS, READONLY
>
> The image looks perfectly fine so far.  Now, perform the objcopy:
>
> 	arm--netbsdelf-objcopy -O a.out-arm-netbsd -R .ident -R .sbss \
> 	    netbsd netbsd.aout
>
> Now we have:
>
> netbsd.aout:     file format a.out-arm-netbsd
> netbsd.aout
> architecture: arm, flags 0x000001be:
> EXEC_P, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS, WP_TEXT, D_PAGED
> start address 0xf0000000
>
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         0015d000  effff020  effff020  00000020  2**4
>                   CONTENTS, ALLOC, LOAD, CODE
>   1 .data         00007000  f015d000  f015d000  0015d020  2**4
>                   CONTENTS, ALLOC, LOAD, DATA
>   2 .bss          000252a0  f0164000  f0164000  00000000  2**4
>                   ALLOC
>
> Now, note:
>
> 	* VMA and LMA are wrong -- they both are 0x1000 too low.
>
> 	* The start address is wrong.  It needs to be 0x20 higher
> 	  than it is (to match the file offset of .text).
>
> Now, if I futz the start address with --adjust-start=32, I get something
> that's a little closer to correct:
>
> netbsd.aout:     file format a.out-arm-netbsd
> netbsd.aout
> architecture: arm, flags 0x000001be:
> EXEC_P, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS, WP_TEXT, D_PAGED
> start address 0xf0000020
>
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         0015d000  f0000020  f0000020  00000020  2**4
>                   CONTENTS, ALLOC, LOAD, CODE
>   1 .data         00007000  f015e000  f015e000  0015d020  2**4
>                   CONTENTS, ALLOC, LOAD, DATA
>   2 .bss          000252a0  f0165000  f0165000  00000000  2**4
>                   ALLOC
>
> However, the image still doesn't work.  The original a.out disassembles
> like so:
>
> /users/thorpej/netbsd.arm-aout:     file format a.out-arm-netbsd
>
> Disassembly of section .text:
>
> f0000020 <_kernel_text>:
> f0000020:       e28f1078        add     r1, pc, #120    ; 0x78
> f0000024:       e8912006        ldmia   r1, {r1, r2, sp}
> f0000028:       e0422001        sub     r2, r2, r1
> f000002c:       e3a03000        mov     r3, #0  ; 0x0
> f0000030:       e4813004        str     r3, [r1], #4
> f0000034:       e2522004        subs    r2, r2, #4      ; 0x4
> f0000038:       cafffffc        bgt     f0000030 <_kernel_text+0x10>
> f000003c:       e3a0b000        mov     fp, #0  ; 0x0
> f0000040:       eb060034        bl      f0180118 <_initarm>
>
> The elf->a.out image disassembles like this:
>
> netbsd.aout:     file format a.out-arm-netbsd
>
> Disassembly of section .text:
>
> f0000020 <kernel_text+0x20>:
> f0000020:       e28f1078        add     r1, pc, #120    ; 0x78
> f0000024:       e8912006        ldmia   r1, {r1, r2, sp}
> f0000028:       e0422001        sub     r2, r2, r1
> f000002c:       e3a03000        mov     r3, #0  ; 0x0
> f0000030:       e4813004        str     r3, [r1], #4
> f0000034:       e2522004        subs    r2, r2, #4      ; 0x4
> f0000038:       cafffffc        bgt     f0000030 <kernel_text+0x30>
> f000003c:       e3a0b000        mov     fp, #0  ; 0x0
> f0000040:       eb0524ab        bl      f01492f4 <initarm+0x20>
>
> The problem here ought to be obvious (check out the last insn in each
> snippet).
>
> Does anyone have any suggestions about what to do here?
>
> --
>         -- Jason R. Thorpe <thorpej@wasabisystems.com>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]