[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