objdump for old ARM7TDMI (ARMv4T) showing instructions for newer architectures?!

objdump for old ARM7TDMI (ARMv4T) showing instructions for newer architectures?!

[chris]

Hello!  I care about the success of GNU very much and wanted some feedback on
what to do about a potential bug in objdump for ARM....

I'm examining the output of "objdump -D --target=binary -m arm7tdmi" and seeing
instructions that do not exist on the ancient ARM7TDMI cores.

For example, mrcc, blx and ldc2 only appeared in ARMv5 or later but I see them
in the output with command line switches above.

(I see same problems with "-m armv4t".)

I'm using version 2.19.1-multiarch from Ubuntu 9.04.

Is this a genuine bug or must I use different switches.

Sincerely,

chris

P.S. I sent this to the binutils list too since wasn't sure which to send it
to.

Re: objdump for old ARM7TDMI (ARMv4T) showing instructions for newer architectures?!

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

Hi Chris,

> Hello!  I care about the success of GNU very much 

Thanks very much for supporting the GNU Project.

> and wanted some feedback on
> what to do about a potential bug in objdump for ARM....

The best thing to do is to file a bug report here:

   http://sourceware.org/bugzilla/

> I'm examining the output of "objdump -D --target=binary -m arm7tdmi" and seeing
> instructions that do not exist on the ancient ARM7TDMI cores.

> Is this a genuine bug or must I use different switches.

It is a genuine bug.

Have a go with the attached patch and see if it fixes the problem for you.

Cheers
   Nick

[-- Attachment #2: arm-dis.c.patch --]
[-- Type: text/plain, Size: 2892 bytes --]

Index: opcodes/arm-dis.c
===================================================================
RCS file: /cvs/src/src/opcodes/arm-dis.c,v
retrieving revision 1.97
diff -c -3 -p -r1.97 arm-dis.c
*** opcodes/arm-dis.c	15 Jun 2009 15:42:34 -0000	1.97
--- opcodes/arm-dis.c	16 Jun 2009 13:54:34 -0000
*************** print_insn_neon (struct disassemble_info
*** 2665,2670 ****
--- 2665,2702 ----
    return FALSE;
  }
  
+ /* Given a bfd_mach_arm_XXX value, returns a bitmask of the
+    corresponding base ARM architecture(s) supported by that
+    type of CPU.  FIXME: This could more efficiently implemented
+    as a constant array, although it would also be less robust.  */
+ 
+ static unsigned long
+ arm_arch_from_mach (unsigned long mach)
+ {
+   switch (mach)
+     {
+       /* If the user has not specified a machine
+ 	 type, allow all architecture types.  */
+     case bfd_mach_arm_unknown: return -1UL;
+     case bfd_mach_arm_2:       return ARM_AEXT_V2;
+     case bfd_mach_arm_2a:      return ARM_AEXT_V2;
+     case bfd_mach_arm_3:       return ARM_AEXT_V3;
+     case bfd_mach_arm_3M:      return ARM_AEXT_V3M;
+     case bfd_mach_arm_4:       return ARM_AEXT_V4;
+     case bfd_mach_arm_4T:      return ARM_AEXT_V4T;
+     case bfd_mach_arm_5:       return ARM_AEXT_V5;
+     case bfd_mach_arm_5T:      return ARM_AEXT_V5T;
+     case bfd_mach_arm_5TE:     return ARM_AEXT_V5TE;
+     case bfd_mach_arm_XScale:  return ARM_AEXT_V5TE;
+     case bfd_mach_arm_ep9312:  return ARM_AEXT_V4T;
+     case bfd_mach_arm_iWMMXt:  return ARM_AEXT_V5TE;
+     case bfd_mach_arm_iWMMXt2: return ARM_AEXT_V5TE;
+     default:
+       abort ();
+     }
+ }
+ 
+ 
  /* Print one ARM instruction from PC on INFO->STREAM.  */
  
  static void
*************** print_insn_arm (bfd_vma pc, struct disas
*** 2687,2692 ****
--- 2719,2727 ----
  	  && info->mach != bfd_mach_arm_iWMMXt)
  	insn = insn + IWMMXT_INSN_COUNT;
  
+       if ((insn->arch & (* (unsigned long *) info->private_data)) == 0)
+ 	continue;
+ 	
        if ((given & insn->mask) == insn->value
  	  /* Special case: an instruction with all bits set in the condition field
  	     (0xFnnn_nnnn) is only matched if all those bits are set in insn->mask,
*************** print_insn (bfd_vma pc, struct disassemb
*** 3991,3996 ****
--- 4026,4042 ----
        info->disassembler_options = NULL;
      }
  
+   if (info->private_data == NULL)
+     {
+       static unsigned long arch;
+ 
+       /* Compute the architecture bitmask from the machine number.
+ 	 Note: This assumes that the machine number will not change
+ 	 during disassembly....  */
+       arch = arm_arch_from_mach (info->mach);
+       info->private_data = & arch;
+     }
+   
    /* Decide if our code is going to be little-endian, despite what the
       function argument might say.  */
    little_code = ((info->endian_code == BFD_ENDIAN_LITTLE) || little);

Re: objdump for old ARM7TDMI (ARMv4T) showing instructions for newer architectures?!

[Richard Earnshaw]

On Tue, 2009-06-16 at 15:00 +0100, Nick Clifton wrote:
> Hi Chris,
> 
> > Hello!  I care about the success of GNU very much 
> 
> Thanks very much for supporting the GNU Project.
> 
> > and wanted some feedback on
> > what to do about a potential bug in objdump for ARM....
> 
> The best thing to do is to file a bug report here:
> 
>    http://sourceware.org/bugzilla/
> 
> > I'm examining the output of "objdump -D --target=binary -m arm7tdmi" and seeing
> > instructions that do not exist on the ancient ARM7TDMI cores.
> 
> > Is this a genuine bug or must I use different switches.

Presumably the code was compiled for some other CPU, if not, then the
bug is in the compiler/assembler that allowed such instructions to be
generated.

> 
> It is a genuine bug.

I'd call it a mis-feature rather than a bug; but it would be nice to fix
it.

> 
> Have a go with the attached patch and see if it fixes the problem for you.
> 

I don't think this works for EABI targets.  They use the attributes
system to record the ISA version.

R.

Re: objdump for old ARM7TDMI (ARMv4T) showing instructions for newer architectures?!

[Nick Clifton]

Hi Richard,

>> It is a genuine bug.
> 
> I'd call it a mis-feature rather than a bug; but it would be nice to fix
> it.

Fair enough.

>> Have a go with the attached patch and see if it fixes the problem for you.
> 
> I don't think this works for EABI targets.  They use the attributes
> system to record the ISA version.

I think that it should work.  The restriction on the decoding of 
instructions is based on the value set by the -m command line switch 
passed to objdump.  The default, if -m is not used, is to disassemble 
everything without any ISA restrictions.  (This matches the current 
behaviour of the disassembler).

Cheers
   Nick

Re: objdump for old ARM7TDMI (ARMv4T) showing instructions for newer architectures?!

[Paul Brook]

On Tuesday 16 June 2009, Nick Clifton wrote:
> +       if ((insn->arch & (* (unsigned long *) info->private_data)) == 0)
> +       continue;

Insn->arch values in arm-dis.c are bogus, and have been for some time (since 
we got more than 32 bit flags).

Paul

Re: objdump for old ARM7TDMI (ARMv4T) showing instructions for newer architectures?!

[Nick Clifton]

Hi Paul,

> On Tuesday 16 June 2009, Nick Clifton wrote:
>> +       if ((insn->arch & (* (unsigned long *) info->private_data)) == 0)
>> +       continue;
> 
> Insn->arch values in arm-dis.c are bogus, and have been for some time (since 
> we got more than 32 bit flags).

Well phoo.  They seem to work though.  What is the officially correct 
way of determining the architectures that support a given instruction ?

Cheers
   Nick

Re: objdump for old ARM7TDMI (ARMv4T) showing instructions for newer architectures?!

[Paul Brook]

> >> +       if ((insn->arch & (* (unsigned long *) info->private_data)) ==
> >
> > Insn->arch values in arm-dis.c are bogus, and have been for some time
> > (since we got more than 32 bit flags).
>
> Well phoo.  They seem to work though.

There's currently only limited overlap between different bitflags, so you 
probably wouldn't notice with v4 code.

> What is the officially correct way of determining the architectures that
> support a given instruction ?

Probably something along the lines of what is used in gas/config/tc-arm.c 
(ARM_CPU_HAS_FEATURE et al).

Paul

Re: objdump for old ARM7TDMI (ARMv4T) showing instructions for newer architectures?!

[chris]

On Tue, Jun 16, 2009 at 03:00:07PM +0100, Nick Clifton wrote:
> The best thing to do is to file a bug report here:
>
>   http://sourceware.org/bugzilla/

> Have a go with the attached patch and see if it fixes the problem for you.

Nick

Thanks for your reply.
I filed a bug report as you suggested and tried to apply your patch to
binutils-2.19.51 found at ftp://sourceware.org/pub/binutils/snapshots/
to test it for you.

It appears the binutils at that URL doesn't have ARM support.  Is there another
site I must go to the get multiarch version of binutils?

Chris

Re: objdump for old ARM7TDMI (ARMv4T) showing instructions for newer architectures?!

[Ian Lance Taylor]

chris@seberino.org writes:

> I filed a bug report as you suggested and tried to apply your patch to
> binutils-2.19.51 found at ftp://sourceware.org/pub/binutils/snapshots/
> to test it for you.
>
> It appears the binutils at that URL doesn't have ARM support.  Is there another
> site I must go to the get multiarch version of binutils?

The binutils snapshots do have ARM support.  There is no separate
multiarch version of the binutils.  What are you doing that makes you
think that the snapshots don't have ARM support?

Ian

Re: objdump for old ARM7TDMI (ARMv4T) showing instructions for newer architectures?!

[chris]

On Tue, Jun 16, 2009 at 05:30:50PM -0700, Ian Lance Taylor wrote:
> The binutils snapshots do have ARM support.  There is no separate
> multiarch version of the binutils.  What are you doing that makes you
> think that the snapshots don't have ARM support?

Thanks for chiming in.  I did a standard build from source and then tried to do...

objdump -D --target=binary -m arm7tdmi foo

for some file foo and got this for the output...


foo:     file format binary

./objdump: Can't use supplied machine arm7tdmi


(-m armv4t gave "./objdump: Can't use supplied machine armv4t")

These worked in Ubuntu's objdump when I installed what Ubuntu calls their multiarch version of
binutils.

cs

Re: objdump for old ARM7TDMI (ARMv4T) showing instructions for newer architectures?!

[Ian Lance Taylor]

chris@seberino.org writes:

> On Tue, Jun 16, 2009 at 05:30:50PM -0700, Ian Lance Taylor wrote:
>> The binutils snapshots do have ARM support.  There is no separate
>> multiarch version of the binutils.  What are you doing that makes you
>> think that the snapshots don't have ARM support?
>
> Thanks for chiming in.  I did a standard build from source and then tried to do...

Did you specify a --target option to configure, as described in
binutils/README?

Ian

Re: objdump for old ARM7TDMI (ARMv4T) showing instructions for newer architectures?!

[chris]

On Tue, Jun 16, 2009 at 08:09:25PM -0700, Ian Lance Taylor wrote:
> Did you specify a --target option to configure, as described in
> binutils/README?

Now I did.  I applied Nick's patch and it works quite nicely.
blx is gone as it should be.

May I mention 2 more instructions that should be removed from ARM7TDMI that I
noticed?  It'd be much appreciated if added to your patch.  I'll test it for
you if you want.

Please remove mrrc and ldc2 as well.

I happen to be writing an ARM7TDMI disassembler, assembler and emulator as a
personal learning project.  If you wish, I'll keep looking very carefully at
objdump output for ARM7TDMI and tell you any other things I notice.

cs

Re: objdump for old ARM7TDMI (ARMv4T) showing instructions for newer architectures?!

[Dave Korn]

chris@seberino.org wrote:
> On Tue, Jun 16, 2009 at 05:30:50PM -0700, Ian Lance Taylor wrote:
>> The binutils snapshots do have ARM support.  There is no separate
>> multiarch version of the binutils.  What are you doing that makes you
>> think that the snapshots don't have ARM support?
> 
> Thanks for chiming in.  I did a standard build from source and then tried to do...
> 
> objdump -D --target=binary -m arm7tdmi foo
> 
> for some file foo and got this for the output...
> 
> 
> foo:     file format binary
> 
> ./objdump: Can't use supplied machine arm7tdmi
> 
> 
> (-m armv4t gave "./objdump: Can't use supplied machine armv4t")
> 
> These worked in Ubuntu's objdump when I installed what Ubuntu calls their multiarch version of
> binutils.
> 
> cs

  Sounds like Ubuntu configured their binutils with "--enable-targets=all";
you either need to do likewise, or build specific arm-targeted binutils.

    cheers,
      DaveK

Minor inconsistent behaviors with objdump wondering about...

[chris]

Nick

(So far your second objdump patch looks good.  I'll do more testing soon.)

I wanted to get your feedback on 2 minor things I noticed about objdump.
This was specifically found on a raw ARM7TDMI binary if that matters...

1. When an instruction contains a number, objdump likes to display this in base
   10 and then add a comment that displays it in hex like so....

   e.g.  170:  c342191f      cmpgt        r2, #507904   ; 0x7c000

   I've noticed sometimes the hex comment does NOT appear.  I've tried to find
   the pattern on when it appears and doesn't appear and I can't.  It appears
   for some small numbers but not for other small numbers.

2. When objdump detects an undefined instruction, it sometimes reprints the
   instruction and sometimes it doesn't....

   e.g  168:    f5e25a8f  undefined instruction 0xf5e25a8f
   and    94:   77c1cdb4  undefined

   I've tried to find the pattern for this selection too and it isn't as
   obvious as you might think.

   Do we want ALL undefined's to be one way or perhaps there is a reason to
   have the variation?

Sincerely,

Chris

Re: Minor inconsistent behaviors with objdump wondering about...

[Nick Clifton]

Hi Chris,

> 1. When an instruction contains a number, objdump likes to display this in base
>    10 and then add a comment that displays it in hex like so....
> 
>    e.g.  170:  c342191f      cmpgt        r2, #507904   ; 0x7c000
> 
>    I've noticed sometimes the hex comment does NOT appear.  I've tried to find
>    the pattern on when it appears and doesn't appear and I can't.  It appears
>    for some small numbers but not for other small numbers.
> 
> 2. When objdump detects an undefined instruction, it sometimes reprints the
>    instruction and sometimes it doesn't....
> 
>    e.g  168:    f5e25a8f  undefined instruction 0xf5e25a8f
>    and    94:   77c1cdb4  undefined
> 
>    I've tried to find the pattern for this selection too and it isn't as
>    obvious as you might think.
> 
>    Do we want ALL undefined's to be one way or perhaps there is a reason to
>    have the variation?

There is no good reason for either of these variations in behaviour so 
if you want to please open a new bug report for them.  (Including a test 
case to reproduce the problem will really help).

Cheers
   Nick

Re: Minor inconsistent behaviors with objdump wondering about...

[chris]

On Thu, Jun 18, 2009 at 11:40:55AM +0100, Nick Clifton wrote:
> There is no good reason for either of these variations in behaviour so
> if you want to please open a new bug report for them.  (Including a test
> case to reproduce the problem will really help).

Done!  See here:

http://sourceware.org/bugzilla/show_bug.cgi?id=10297

Thanks for all you do for GNU.  I really appreciate it.

cs