------- Additional Comments From nickc at redhat dot com  2010-07-16 15:59 
-------
Hi Andrew,
  This is not a GAS bug, but rather a "feature" of the assembly code generated
by gcc.  Have a look at the asm.s file in your tarball.  Just before the start
of the exhibit_bug function there is a ".set reorder" directive which tells gas
that it is allowed (and expected) to reorder the instruction sequence, including
changing the instruction in the delay slot of jumps and branches.

  The ".set reorder" directive is there because of the __asm__ statements in the
exhibit_bug function.  GCC has put the directive there because it cannot be sure
that there will not be any hazards between the code inside the asm statement(s)
and the code that gcc itself has generated.  Thus it needs to assembler to be
able to reorder instructions to avoid those hazards if they exist.

  One possible workaround for this problem is to add a ".set noreorder"
directive at the start of exhibit_bug, like this:

  void exhibit_bug()
  {
    __asm__ volatile (".set noreorder");
    int x = 10;
    set_hex(hex_base,5);

    set_hex(hex_base,7);

    __asm__ volatile ("break");

    while(1)
      {
        set_hex(hex_base,x++);
        __asm__ volatile ("break");
      }
  }

Note, you would have to do this at the start of *every* function that makes use
of your __asm__ volatile ("break") inline assembler.

Cheers
  Nick


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Reply via email to