Re: Binutils v2.21.1a ARM mrs disassembler.

[Bill Pringlemeir]

On 10 May 2012, address@hidden 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.