On 10 May 2012, matthew.gretton-d...@arm.com wrote: On Wed, May 09, 2012 at 05:14:56PM +0100, Bill Pringlemeir wrote:
>> I have issues decoding 'mrs sp,spsr' with objdump for an ARM target. >> 00000000 <irq_handler>: >> 0: e14fd000 .word 0xe14fd000 >> I only pass '--disassemble'. The objdump was built with > I cannot reproduce this behaviour with binutils built from plain FSF > sources. > Can you please provide a small test case showing the source passed > into the assembler; how the assembler is invoked; and how objdump is > invoked on the assembler's output? Thanks. I also can not reproduce this will a small assembler files and object. It has something to do with other instructions/headers in the object file. The project is the OKL4 'microvisor'. It was compiled with a CodeSourcery tool set. $ /opt/arm-2009q1/arm-none-eabi/bin/gcc --version gcc (Sourcery G++ Lite 2009q1-161) 4.3.3 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The copyright to the source is not owned by me, so I can not post that. I tried to get a reduced file that exhibits this. The project is made up of mixed assembler and c, with many '.section' definitions and many 'C' routines that are marked 'no_return'. It seems that 'interrupt.o' disassembles correctly, but a partially relocated object files does not [ a bsp/soc library and other modules are linked to produce a final binary]. Here are the build commands, $CC --std=gnu99 -O2 -g -nostdlib -nostdinc -fno-builtin-bzero -fomit-frame-pointer -mword-relocations -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wundef -Wpointer-arith -Wno-nonnull -Werror -Wnested-externs -march=armv5te -mcpu=arm926ej-s -x assembler-with-cpp -DARM_PID_RELOC=1 -DARM_SHARED_DOMAINS=1 -DTHREAD_SAFE=1 -DTOOLCHAIN_GCC -DARCH_ARM -DENDIAN_LITTLE -D__ARMv__=5 -DARCH_ARMV5 -DARCH_VER=5 -DMAX_NUM_CPUS=1UL -DASM_MAX_NUM_CPUS=1 -DNDEBUG -DOKL4_KERNEL -DASSEMBLY -I$SRC_DIR/include $SRC_DIR/arch/armv5/kernel/kernel_base/src/interrupt.spp -c -o $OBJ_DIR/interrupt.o $LD -N --strip-debug -r $OBJ_DIR/mmu_init.o $OBJ_DIR/vcpu_exception.o $OBJ_DIR/linux_helpers.o $OBJ_DIR/vcpu_syscall.o $OBJ_DIR/user_write.o $OBJ_DIR/copy_in_buf.o $OBJ_DIR/copy_out_buf.o $OBJ_DIR/user_read.o $OBJ_DIR/copy_in.o $OBJ_DIR/copy_out.o $OBJ_DIR/channel_copy_from_user.o $OBJ_DIR/channel_copy_to_user.o $OBJ_DIR/fault.o $OBJ_DIR/init.o $OBJ_DIR/exception.o $OBJ_DIR/atomic.o $OBJ_DIR/switch_to.o $OBJ_DIR/vectors.o $OBJ_DIR/syscall.o $OBJ_DIR/rvct.o $OBJ_DIR/preemption-rvct.o $OBJ_DIR/linker-rvct.o $OBJ_DIR/phys_reloc.o $OBJ_DIR/interrupt.o $OBJ_DIR/elfweaver_info.o $OBJ_DIR/kernel.o --start-group $( $CC --std=gnu99 -O2 -g -nostdlib -nostdinc -fno-builtin-bzero -fomit-frame-pointer -mword-relocations -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wundef -Wpointer-arith -Wno-nonnull -Werror -Wnested-externs -march=armv5te -mcpu=arm926ej-s --print-libgcc-file-name) --end-group -o $BIN_DIR/arm926ej-s-r0p3-microvisor.o Where $LD and $CC are codesourcery v4.3.3/2009q1-161 binaries for x86 Linux. The host is Ubuntu x86_64. I understand if no one cares about this. I was concerned I found a simple issue in the decoder. I think arm-dis.c, {ARM_EXT_V3, 0x01000000, 0x0fb00cff, "mrs%c\t%12-15R, %R"}, should be doing the decoding. It seems to be fine for most objects. Fwiw, Bill Pringlemeir. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils