[LLVMbugs] [Bug 18487] New: Fix rules on what ".set micromips" applies to

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Wed Jan 15 07:01:05 PST 2014


http://llvm.org/bugs/show_bug.cgi?id=18487

            Bug ID: 18487
           Summary: Fix rules on what ".set micromips" applies to
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: MC
          Assignee: unassignedbugs at nondot.org
          Reporter: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Richard Sandiford says:

Careful!  It's important that all "instruction" labels get marked as
micromips, even if they have no explicit type.  E.g. if you have:

        .set    micromips
        .type   foo, @function
        .ent    foo
foo:
        nop
my_label:
        nop
        .end    foo

then my_label must be treated as micromips:

Symbol table '.symtab' contains 8 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 00000000     0 SECTION LOCAL  DEFAULT    1 .text
     2: 00000000     0 SECTION LOCAL  DEFAULT    2 .data
     3: 00000000     0 SECTION LOCAL  DEFAULT    3 .bss
     4: 00000000     0 SECTION LOCAL  DEFAULT    4 .reginfo
     5: 00000000     0 SECTION LOCAL  DEFAULT    5 .pdr
     6: 00000000     4 FUNC    LOCAL  DEFAULT [MICROMIPS]     1 foo
     7: 00000002     0 NOTYPE  LOCAL  DEFAULT [MICROMIPS]     1 my_label

It looked from the patch like this wouldn't happen.

This is important for things like EH tables, debug info, or other such data,
as well as for alternative entry points.

The syntax for forcing a label to be treated as an instruction label
is ".insn".  So:

f2:
        .insn
        .word   ...

can be used to emit instructions as .words.

I strongly suggest not doing something different for LLVM.  This stuff
is hairy enough as it is without having two different interpretations
of the same assembly.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140115/9e96864f/attachment.html>


More information about the llvm-bugs mailing list