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
