public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* how to embed an arbitrary opcode
@ 2009-06-18 21:26 John Breitenbach
  2009-06-18 21:45 ` Daniel Jacobowitz
  2009-06-19 13:50 ` Nick Clifton
  0 siblings, 2 replies; 10+ messages in thread
From: John Breitenbach @ 2009-06-18 21:26 UTC (permalink / raw)
  To: binutils

Hi,
  I'm looking for a way to embed an arbitrary opcode into an assembly 
file for the ARM architecture.  .long and
friends implicitly mark their data as data, using the $d, and follow it 
with a $a to resume with executable code.

This was a problem because we build code for be8 mode, and the linker 
needs to know what it executable code and
thus what to swap.  Our hand-coded opcode wasn't getting swapped.  
Objdump refuses to disassemble those
opcodes even with the --disassemble-all flag.

binutils version is a bit old, but its new to us:  GNU assembler 
(CodeSourcery 2007q1-10. Marvell 2008q3-13 20081204) 2.17

The current docs and a google search didn't help, and trying ".insn" 
didn't magically work.

I also tried an explicit "$a" in front of my .long, but the assembler 
complains about that.

contents x.S
    wfi
    .long 0xe320f003

wfi is allowed by my assembler with -mcpu=marvell-fv7.

objdump shows that they generate identical values:
t.o:     file format elf32-bigarm

Disassembly of section .text:

00000000 <.text>:
   0:   e320f003        wfi
   4:   e320f003        .word   0xe320f003

readelf shows that we switch to data at offset 4.

Thanks for any advice, John.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: how to embed an arbitrary opcode
  2009-06-18 21:26 how to embed an arbitrary opcode John Breitenbach
@ 2009-06-18 21:45 ` Daniel Jacobowitz
  2009-06-18 23:15   ` John Breitenbach
  2009-06-19 13:50 ` Nick Clifton
  1 sibling, 1 reply; 10+ messages in thread
From: Daniel Jacobowitz @ 2009-06-18 21:45 UTC (permalink / raw)
  To: John Breitenbach; +Cc: binutils, Daniel Gutson

On Thu, Jun 18, 2009 at 04:18:49PM -0400, John Breitenbach wrote:
> Hi,
>  I'm looking for a way to embed an arbitrary opcode into an assembly file 
> for the ARM architecture.  .long and
> friends implicitly mark their data as data, using the $d, and follow it  
> with a $a to resume with executable code.
>
> This was a problem because we build code for be8 mode, and the linker  
> needs to know what it executable code and
> thus what to swap.  Our hand-coded opcode wasn't getting swapped.   
> Objdump refuses to disassemble those
> opcodes even with the --disassemble-all flag.
>
> binutils version is a bit old, but its new to us:  GNU assembler  
> (CodeSourcery 2007q1-10. Marvell 2008q3-13 20081204) 2.17

There's no way to do this even in current binutils - but Daniel
Gutson's been working on it recently.  I think we'll have
a patch posted for this soon.

-- 
Daniel Jacobowitz
CodeSourcery

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: how to embed an arbitrary opcode
  2009-06-18 21:45 ` Daniel Jacobowitz
@ 2009-06-18 23:15   ` John Breitenbach
  0 siblings, 0 replies; 10+ messages in thread
From: John Breitenbach @ 2009-06-18 23:15 UTC (permalink / raw)
  To: John Breitenbach, binutils, Daniel Gutson

Daniel Jacobowitz wrote:
>> There's no way to do this even in current binutils - but Daniel
>> Gutson's been working on it recently.  I think we'll have
>> a patch posted for this soon.
>>     
That's good to know ... I'll be watching for it.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: how to embed an arbitrary opcode
  2009-06-18 21:26 how to embed an arbitrary opcode John Breitenbach
  2009-06-18 21:45 ` Daniel Jacobowitz
@ 2009-06-19 13:50 ` Nick Clifton
  2009-06-19 14:17   ` Richard Earnshaw
                     ` (2 more replies)
  1 sibling, 3 replies; 10+ messages in thread
From: Nick Clifton @ 2009-06-19 13:50 UTC (permalink / raw)
  To: John Breitenbach; +Cc: binutils

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

Hi John,

>  I'm looking for a way to embed an arbitrary opcode into an assembly 
> file for the ARM architecture. 

Is there a particular reason why you cannot just include the textual 
version of the opcode you want and have it assembled as normal ?

> Objdump refuses to disassemble those opcodes even with the 
 > --disassemble-all flag.

This has now been fixed in the mainline sources.

>    .long 0xe320f003

Currently there is no way to achieve the effect you desire.  But all is 
not lost, this being free software and all.  So, please try out the 
attached patch which adds two new pseudo ops to the ARM port of GAS:

   .iword <expression>[,<expression>]*
   .ishort <expression>[,<expression>]*

which can be used to insert 32-bit and 16-bit values respectively into 
the output stream and mark them as instructions not data.

Cheers
   Nick




[-- Attachment #2: arm.iword.patch --]
[-- Type: text/plain, Size: 4831 bytes --]

Index: gas/config/tc-arm.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-arm.c,v
retrieving revision 1.387
diff -c -3 -p -r1.387 tc-arm.c
*** gas/config/tc-arm.c	18 Jun 2009 16:36:02 -0000	1.387
--- gas/config/tc-arm.c	19 Jun 2009 13:29:42 -0000
*************** static void add_unwind_opcode (valueT, i
*** 2951,2979 ****
  static void flush_pending_unwind (void);
  
  /* Directives: Data.  */
- 
  static void
! s_arm_elf_cons (int nbytes)
  {
-   expressionS exp;
- 
- #ifdef md_flush_pending_output
-   md_flush_pending_output ();
- #endif
- 
-   if (is_it_end_of_statement ())
-     {
-       demand_empty_rest_of_line ();
-       return;
-     }
- 
- #ifdef md_cons_align
-   md_cons_align (nbytes);
- #endif
- 
-   mapping_state (MAP_DATA);
    do
      {
        int reloc;
        char *base = input_line_pointer;
  
--- 2951,2962 ----
  static void flush_pending_unwind (void);
  
  /* Directives: Data.  */
  static void
! arm_elf_cons_worker (int nbytes)
  {
    do
      {
+       expressionS exp;
        int reloc;
        char *base = input_line_pointer;
  
*************** s_arm_elf_cons (int nbytes)
*** 2984,2989 ****
--- 2967,2973 ----
        else
  	{
  	  char *before_reloc = input_line_pointer;
+ 
  	  reloc = parse_reloc (&input_line_pointer);
  	  if (reloc == -1)
  	    {
*************** s_arm_elf_cons (int nbytes)
*** 3017,3022 ****
--- 3001,3007 ----
  		  char *p = input_line_pointer;
  		  int offset;
  		  char *save_buf = alloca (input_line_pointer - base);
+ 
  		  memcpy (save_buf, base, input_line_pointer - base);
  		  memmove (base + (input_line_pointer - before_reloc),
  			   base, before_reloc - base);
*************** s_arm_elf_cons (int nbytes)
*** 3040,3045 ****
--- 3025,3060 ----
    demand_empty_rest_of_line ();
  }
  
+ static void
+ s_arm_elf_cons (int nbytes)
+ {
+   if (is_it_end_of_statement ())
+     {
+       demand_empty_rest_of_line ();
+       return;
+     }
+ 
+   md_cons_align (nbytes); /* Sets mapping state to MAPPING_DATA.  */
+ 
+   arm_elf_cons_worker (nbytes);
+ }
+ 
+ /* Like s_arm_elf_cons but do not use md_cons_align and
+    set the mapping state to MAP_ARM (if nbytes == 4) or
+    MAP_THUMB (if nbytes == 2).  */
+ 
+ static void
+ s_arm_elf_iword (int nbytes)
+ {
+   if (is_it_end_of_statement ())
+     {
+       demand_empty_rest_of_line ();
+       return;
+     }
+ 
+   mapping_state (nbytes == 4 ? MAP_ARM : MAP_THUMB);
+   arm_elf_cons_worker (nbytes);
+ }
  
  /* Parse a .rel31 directive.  */
  
*************** const pseudo_typeS md_pseudo_table[] =
*** 3958,3966 ****
    { "object_arch", s_arm_object_arch,	0 },
    { "fpu",	   s_arm_fpu,	  0 },
  #ifdef OBJ_ELF
!   { "word",	   s_arm_elf_cons, 4 },
!   { "long",	   s_arm_elf_cons, 4 },
!   { "rel31",	   s_arm_rel31,	  0 },
    { "fnstart",		s_arm_unwind_fnstart,	0 },
    { "fnend",		s_arm_unwind_fnend,	0 },
    { "cantunwind",	s_arm_unwind_cantunwind, 0 },
--- 3973,3983 ----
    { "object_arch", s_arm_object_arch,	0 },
    { "fpu",	   s_arm_fpu,	  0 },
  #ifdef OBJ_ELF
!   { "word",	        s_arm_elf_cons, 4 },
!   { "long",	        s_arm_elf_cons, 4 },
!   { "iword",            s_arm_elf_iword, 4 },
!   { "ishort",           s_arm_elf_iword, 2 },
!   { "rel31",	        s_arm_rel31,	  0 },
    { "fnstart",		s_arm_unwind_fnstart,	0 },
    { "fnend",		s_arm_unwind_fnend,	0 },
    { "cantunwind",	s_arm_unwind_cantunwind, 0 },
Index: gas/doc/c-arm.texi
===================================================================
RCS file: /cvs/src/src/gas/doc/c-arm.texi,v
retrieving revision 1.56
diff -c -3 -p -r1.56 c-arm.texi
*** gas/doc/c-arm.texi	2 Apr 2009 09:43:56 -0000	1.56
--- gas/doc/c-arm.texi	19 Jun 2009 13:29:42 -0000
*************** Must be preceded by a @code{.personality
*** 564,569 ****
--- 564,586 ----
  directive.
  
  @c IIIIIIIIIIIIIIIIIIIIIIIIII
+ 
+ @cindex @code{ishort} directive, ARM
+ @item ishort @var{expression} [, @var{expression}]*
+ Inserts one or more comma separated expressions into the output stream
+ as 16-bit values and marks them as being THUMB instructions.  This
+ directive is only supported in ELF based ARM toolchains.  Note: the
+ generic GAS directive @code{.short} does the same thing, but it marks
+ the values as being data not instructions.
+ 
+ @cindex @code{iword} directive, ARM
+ @item iword @var{expression} [, @var{expression}]*
+ Inserts one or more comma separated expressions into the output stream
+ as 32-bit values and marks them as being ARM instructions.  This
+ directive is only supported in ELF based ARM toolchains.  Note: the
+ generic GAS directive @code{.word} does the same thing, but it marks
+ the values as being data not instructions.
+ 
  @c JJJJJJJJJJJJJJJJJJJJJJJJJJ
  @c KKKKKKKKKKKKKKKKKKKKKKKKKK
  @c LLLLLLLLLLLLLLLLLLLLLLLLLL

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: how to embed an arbitrary opcode
  2009-06-19 13:50 ` Nick Clifton
@ 2009-06-19 14:17   ` Richard Earnshaw
  2009-06-19 14:20     ` Nick Clifton
  2009-06-19 14:37   ` Paul Brook
  2009-06-19 14:57   ` John Breitenbach
  2 siblings, 1 reply; 10+ messages in thread
From: Richard Earnshaw @ 2009-06-19 14:17 UTC (permalink / raw)
  To: Nick Clifton; +Cc: John Breitenbach, binutils

On Fri, 2009-06-19 at 14:33 +0100, Nick Clifton wrote:
> Hi John,
> 
> >  I'm looking for a way to embed an arbitrary opcode into an assembly 
> > file for the ARM architecture. 
> 
> Is there a particular reason why you cannot just include the textual 
> version of the opcode you want and have it assembled as normal ?
> 
> > Objdump refuses to disassemble those opcodes even with the 
>  > --disassemble-all flag.
> 
> This has now been fixed in the mainline sources.
> 
> >    .long 0xe320f003
> 
> Currently there is no way to achieve the effect you desire.  But all is 
> not lost, this being free software and all.  So, please try out the 
> attached patch which adds two new pseudo ops to the ARM port of GAS:
> 
>    .iword <expression>[,<expression>]*
>    .ishort <expression>[,<expression>]*
> 
> which can be used to insert 32-bit and 16-bit values respectively into 
> the output stream and mark them as instructions not data.
> 
> Cheers
>    Nick
> 

Yay!  Something I've wanted for a long time...

One question.  What happens if .iword is used in Thumb mode, or .ishort
in ARM mode?  I think it would be better to just have .insn (or .inst),
which takes 32-bit numbers in ARM state and 16-bit numbers in thumb.
The assembler has to know what state it's in anyway in order to generate
the correct mapping symbol information.

R.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: how to embed an arbitrary opcode
  2009-06-19 14:17   ` Richard Earnshaw
@ 2009-06-19 14:20     ` Nick Clifton
  2009-06-19 14:56       ` Richard Earnshaw
  0 siblings, 1 reply; 10+ messages in thread
From: Nick Clifton @ 2009-06-19 14:20 UTC (permalink / raw)
  To: Richard Earnshaw; +Cc: John Breitenbach, binutils

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

Hi Richard,

> Yay!  Something I've wanted for a long time...

:-)

> One question.  What happens if .iword is used in Thumb mode, or .ishort
> in ARM mode?

Well the new pseudos explicitly set the mapping state based on their 
size, so for example if .iword were used in Thumb mode it would cause a 
$a symbol to be emitted at point.  Ie:

   % cat fred.s
         .text
         .global foo
   foo:
         nop
         .iword  0xe320f003
         nop
         .ishort 0x1234
         nop

         .thumb
         .global bar
   bar:
         nop
         .ishort 0x1234
         nop
         .iword 0xe320f003
         nop

   % as fred.s -o fred.o
   % objdump -d fred.o
   00000000 <foo>:
    0:   e1a00000        nop                     (mov r0,r0)
    4:   e320f003        wfi
    8:   e1a00000        nop                     (mov r0,r0)
    c:   1234            asrs    r4, r6, #8
    e:   e1a00000        nop                     (mov r0,r0)

   00000012 <bar>:
   12:   46c0            nop                     (mov r8, r8)
   14:   1234            asrs    r4, r6, #8
   16:   46c0            nop                     (mov r8, r8)
   18:   e320f003        wfi
   1c:   46c0            nop                     (mov r8, r8)


> I think it would be better to just have .insn (or .inst),
> which takes 32-bit numbers in ARM state and 16-bit numbers in thumb.
> The assembler has to know what state it's in anyway in order to generate
> the correct mapping symbol information.

I suspect that users are going to want to be able to use this mechanism 
to insert arbitrary ARM or THUMB opcodes at arbitrary places without 
regard to whether the assembler is currently in arm mode or thumb mode.

It would be quite easy to extend the patch however to add a third pseudo 
op (.inst is fine by me) which chooses it size based on the current 
mode.  So attached is an improved version of the patch which does just 
that.  Let me know what you think and if everyone likes it I will check 
it in.  (Along with a testcase based on the fred.s file above).

Cheers
   Nick


[-- Attachment #2: arm.iword.patch --]
[-- Type: text/plain, Size: 5496 bytes --]

Index: gas/config/tc-arm.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-arm.c,v
retrieving revision 1.387
diff -c -3 -p -r1.387 tc-arm.c
*** gas/config/tc-arm.c	18 Jun 2009 16:36:02 -0000	1.387
--- gas/config/tc-arm.c	19 Jun 2009 14:15:35 -0000
*************** static void add_unwind_opcode (valueT, i
*** 2951,2979 ****
  static void flush_pending_unwind (void);
  
  /* Directives: Data.  */
- 
  static void
! s_arm_elf_cons (int nbytes)
  {
-   expressionS exp;
- 
- #ifdef md_flush_pending_output
-   md_flush_pending_output ();
- #endif
- 
-   if (is_it_end_of_statement ())
-     {
-       demand_empty_rest_of_line ();
-       return;
-     }
- 
- #ifdef md_cons_align
-   md_cons_align (nbytes);
- #endif
- 
-   mapping_state (MAP_DATA);
    do
      {
        int reloc;
        char *base = input_line_pointer;
  
--- 2951,2962 ----
  static void flush_pending_unwind (void);
  
  /* Directives: Data.  */
  static void
! arm_elf_cons_worker (int nbytes)
  {
    do
      {
+       expressionS exp;
        int reloc;
        char *base = input_line_pointer;
  
*************** s_arm_elf_cons (int nbytes)
*** 2984,2989 ****
--- 2967,2973 ----
        else
  	{
  	  char *before_reloc = input_line_pointer;
+ 
  	  reloc = parse_reloc (&input_line_pointer);
  	  if (reloc == -1)
  	    {
*************** s_arm_elf_cons (int nbytes)
*** 3017,3022 ****
--- 3001,3007 ----
  		  char *p = input_line_pointer;
  		  int offset;
  		  char *save_buf = alloca (input_line_pointer - base);
+ 
  		  memcpy (save_buf, base, input_line_pointer - base);
  		  memmove (base + (input_line_pointer - before_reloc),
  			   base, before_reloc - base);
*************** s_arm_elf_cons (int nbytes)
*** 3040,3045 ****
--- 3025,3064 ----
    demand_empty_rest_of_line ();
  }
  
+ static void
+ s_arm_elf_cons (int nbytes)
+ {
+   if (is_it_end_of_statement ())
+     {
+       demand_empty_rest_of_line ();
+       return;
+     }
+ 
+   md_cons_align (nbytes); /* Sets mapping state to MAPPING_DATA.  */
+ 
+   arm_elf_cons_worker (nbytes);
+ }
+ 
+ /* Like s_arm_elf_cons but do not use md_cons_align and
+    set the mapping state to MAP_ARM (if nbytes == 4) or
+    MAP_THUMB (if nbytes == 2) or neither (if nbytes == 0).  */
+ 
+ static void
+ s_arm_elf_iword (int nbytes)
+ {
+   if (is_it_end_of_statement ())
+     {
+       demand_empty_rest_of_line ();
+       return;
+     }
+ 
+   if (nbytes)
+     mapping_state (nbytes == 4 ? MAP_ARM : MAP_THUMB);
+   else
+     nbytes = mapstate == MAP_ARM ? 4 : 2;
+ 
+   arm_elf_cons_worker (nbytes);
+ }
  
  /* Parse a .rel31 directive.  */
  
*************** const pseudo_typeS md_pseudo_table[] =
*** 3958,3966 ****
    { "object_arch", s_arm_object_arch,	0 },
    { "fpu",	   s_arm_fpu,	  0 },
  #ifdef OBJ_ELF
!   { "word",	   s_arm_elf_cons, 4 },
!   { "long",	   s_arm_elf_cons, 4 },
!   { "rel31",	   s_arm_rel31,	  0 },
    { "fnstart",		s_arm_unwind_fnstart,	0 },
    { "fnend",		s_arm_unwind_fnend,	0 },
    { "cantunwind",	s_arm_unwind_cantunwind, 0 },
--- 3977,3988 ----
    { "object_arch", s_arm_object_arch,	0 },
    { "fpu",	   s_arm_fpu,	  0 },
  #ifdef OBJ_ELF
!   { "word",	        s_arm_elf_cons, 4 },
!   { "long",	        s_arm_elf_cons, 4 },
!   { "inst",             s_arm_elf_iword, 0 },
!   { "ishort",           s_arm_elf_iword, 2 },  
!   { "iword",            s_arm_elf_iword, 4 },
!   { "rel31",	        s_arm_rel31,	  0 },
    { "fnstart",		s_arm_unwind_fnstart,	0 },
    { "fnend",		s_arm_unwind_fnend,	0 },
    { "cantunwind",	s_arm_unwind_cantunwind, 0 },
Index: gas/doc/c-arm.texi
===================================================================
RCS file: /cvs/src/src/gas/doc/c-arm.texi,v
retrieving revision 1.56
diff -c -3 -p -r1.56 c-arm.texi
*** gas/doc/c-arm.texi	2 Apr 2009 09:43:56 -0000	1.56
--- gas/doc/c-arm.texi	19 Jun 2009 14:15:35 -0000
*************** Must be preceded by a @code{.personality
*** 564,569 ****
--- 564,595 ----
  directive.
  
  @c IIIIIIIIIIIIIIIIIIIIIIIIII
+ 
+ @cindex @code{.inst} directive, ARM
+ @item .inst @var{expression} [, @var{expression}]*
+ Inserts one or more comma separated expressions into the output stream
+ without changing the mapping state (@pxref{ARM Mapping Symbols}).  The
+ size of the values inserted depends upon whether the assembler is
+ currently in ARM mode (32-bit values are inserted) or Thumb mode
+ (16-bit values are inserted) as set by the @var{.code} directive.  
+ This directive is only supported in ELF based ARM toolchains.
+ 
+ @cindex @code{.ishort} directive, ARM
+ @item .ishort @var{expression} [, @var{expression}]*
+ Inserts one or more comma separated expressions into the output stream
+ as 16-bit values and marks them as being THUMB instructions.  This
+ directive is only supported in ELF based ARM toolchains.  Note: the
+ generic GAS directive @code{.short} does the same thing, but it marks
+ the values as being data not instructions.
+ 
+ @cindex @code{.iword} directive, ARM
+ @item .iword @var{expression} [, @var{expression}]*
+ Inserts one or more comma separated expressions into the output stream
+ as 32-bit values and marks them as being ARM instructions.  This
+ directive is only supported in ELF based ARM toolchains.  Note: the
+ generic GAS directive @code{.word} does the same thing, but it marks
+ the values as being data not instructions.
+ 
  @c JJJJJJJJJJJJJJJJJJJJJJJJJJ
  @c KKKKKKKKKKKKKKKKKKKKKKKKKK
  @c LLLLLLLLLLLLLLLLLLLLLLLLLL

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: how to embed an arbitrary opcode
  2009-06-19 13:50 ` Nick Clifton
  2009-06-19 14:17   ` Richard Earnshaw
@ 2009-06-19 14:37   ` Paul Brook
  2009-06-19 15:05     ` Nick Clifton
  2009-06-19 14:57   ` John Breitenbach
  2 siblings, 1 reply; 10+ messages in thread
From: Paul Brook @ 2009-06-19 14:37 UTC (permalink / raw)
  To: binutils, Daniel Gutson; +Cc: Nick Clifton, John Breitenbach

> Currently there is no way to achieve the effect you desire.  But all is
> not lost, this being free software and all.  So, please try out the
> attached patch which adds two new pseudo ops to the ARM port of GAS:
>
>    .iword <expression>[,<expression>]*
>    .ishort <expression>[,<expression>]*
>
> which can be used to insert 32-bit and 16-bit values respectively into
> the output stream and mark them as instructions not data.

I'd rather not do it this way. A naive implementation like this ignores many 
of the complications that arise on Thumb-2 targets.

c.f. http://sourceware.org/ml/binutils/2006-11/msg00250.html

Daniel Gutson is currently working on implementing a variant of (2).

Paul

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: how to embed an arbitrary opcode
  2009-06-19 14:20     ` Nick Clifton
@ 2009-06-19 14:56       ` Richard Earnshaw
  0 siblings, 0 replies; 10+ messages in thread
From: Richard Earnshaw @ 2009-06-19 14:56 UTC (permalink / raw)
  To: Nick Clifton; +Cc: John Breitenbach, binutils

On Fri, 2009-06-19 at 15:17 +0100, Nick Clifton wrote:
> Hi Richard,
> 
> > Yay!  Something I've wanted for a long time...
> 
> :-)
> 
> > One question.  What happens if .iword is used in Thumb mode, or .ishort
> > in ARM mode?
> 
> Well the new pseudos explicitly set the mapping state based on their 
> size, so for example if .iword were used in Thumb mode it would cause a 
> $a symbol to be emitted at point.  Ie:
> 
>    % cat fred.s
>          .text
>          .global foo
>    foo:
>          nop
>          .iword  0xe320f003
>          nop
>          .ishort 0x1234
>          nop
> 
>          .thumb
>          .global bar
>    bar:
>          nop
>          .ishort 0x1234
>          nop
>          .iword 0xe320f003
>          nop
> 
>    % as fred.s -o fred.o
>    % objdump -d fred.o
>    00000000 <foo>:
>     0:   e1a00000        nop                     (mov r0,r0)
>     4:   e320f003        wfi
>     8:   e1a00000        nop                     (mov r0,r0)
>     c:   1234            asrs    r4, r6, #8
>     e:   e1a00000        nop                     (mov r0,r0)
> 
>    00000012 <bar>:
>    12:   46c0            nop                     (mov r8, r8)
>    14:   1234            asrs    r4, r6, #8
>    16:   46c0            nop                     (mov r8, r8)
>    18:   e320f003        wfi
>    1c:   46c0            nop                     (mov r8, r8)
> 

Yuk!

> 
> > I think it would be better to just have .insn (or .inst),
> > which takes 32-bit numbers in ARM state and 16-bit numbers in thumb.
> > The assembler has to know what state it's in anyway in order to generate
> > the correct mapping symbol information.
> 
> I suspect that users are going to want to be able to use this mechanism 
> to insert arbitrary ARM or THUMB opcodes at arbitrary places without 
> regard to whether the assembler is currently in arm mode or thumb mode.
> 

I doubt that.  Anyway, it's no real hardship to put .arm or .thumb in
the sources as well if you want a specific state.

> It would be quite easy to extend the patch however to add a third pseudo 
> op (.inst is fine by me) which chooses it size based on the current 
> mode.  So attached is an improved version of the patch which does just 
> that.  Let me know what you think and if everyone likes it I will check 
> it in.  (Along with a testcase based on the fred.s file above).
> 

My main concern is that .iword generates a 32-bit number, so could be
thought of meaning a 32-bit thumb(2) instruction.  It would be very
confusing to then find it quietly produced an ARM instruction
(especially on cortex-m* processors)!

IMO if you want explicit 16- and 32-bit operations, then I'd go
for .iword in thumb meaning a 32-bit thumb instruction where the most
significant 16 bits of the number represent sub-word 1 and the least
significant 16 bits represent sub-word 2.  Using .ishort when not in
thumb state should be an error.

R.



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: how to embed an arbitrary opcode
  2009-06-19 13:50 ` Nick Clifton
  2009-06-19 14:17   ` Richard Earnshaw
  2009-06-19 14:37   ` Paul Brook
@ 2009-06-19 14:57   ` John Breitenbach
  2 siblings, 0 replies; 10+ messages in thread
From: John Breitenbach @ 2009-06-19 14:57 UTC (permalink / raw)
  To: Nick Clifton; +Cc: John Breitenbach, binutils

Nick Clifton wrote:
> Hi John,
> Is there a particular reason why you cannot just include the textual 
> version of the opcode you want and have it assembled as normal ?
>
I'm trying to use a new cpu, but for various reasons, have not been able 
to complete the switch to a newer toolchain [yet].  This
new cpu supports a handful of new instructions, including wfi, which we 
wanted to exercise, but was not accepted by the older binutils.

>> Objdump refuses to disassemble those opcodes even with the 
> > --disassemble-all flag.
>
> This has now been fixed in the mainline sources.
>
Great!  I'm watching to see how the discussion on the pseudo-op concludes.

Thanks, John

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: how to embed an arbitrary opcode
  2009-06-19 14:37   ` Paul Brook
@ 2009-06-19 15:05     ` Nick Clifton
  0 siblings, 0 replies; 10+ messages in thread
From: Nick Clifton @ 2009-06-19 15:05 UTC (permalink / raw)
  To: Paul Brook, Richard Earnshaw; +Cc: binutils, Daniel Gutson, John Breitenbach

Hi Paul, Hi Richard,

> I'd rather not do it this way. A naive implementation like this ignores many 
> of the complications that arise on Thumb-2 targets.
> 
> c.f. http://sourceware.org/ml/binutils/2006-11/msg00250.html
> 
> Daniel Gutson is currently working on implementing a variant of (2).

OK then, I will withdraw my patch and wait for Daniel to submit his.

Cheers
   Nick


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2009-06-19 14:57 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-06-18 21:26 how to embed an arbitrary opcode John Breitenbach
2009-06-18 21:45 ` Daniel Jacobowitz
2009-06-18 23:15   ` John Breitenbach
2009-06-19 13:50 ` Nick Clifton
2009-06-19 14:17   ` Richard Earnshaw
2009-06-19 14:20     ` Nick Clifton
2009-06-19 14:56       ` Richard Earnshaw
2009-06-19 14:37   ` Paul Brook
2009-06-19 15:05     ` Nick Clifton
2009-06-19 14:57   ` John Breitenbach

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).