[LLVMbugs] [Bug 9067] New: call to stdcall-named function causes AsmParser to choke
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Wed Jan 26 23:19:25 PST 2011
http://llvm.org/bugs/show_bug.cgi?id=9067
Summary: call to stdcall-named function causes AsmParser to
choke
Product: new-bugs
Version: trunk
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: pawel.kunio at gmail.com
CC: llvmbugs at cs.uiuc.edu
Hello,
Recently there has been revision 114154 - MC/AsmParser: Add support for 'a +
4 at GOTPCREL' added to the trunk. The submitted patch adds check whether @ suffix
is one of list of predefined ones (done in lib/MC/MCParser/AsmParser.cpp around
line 512).
Code (reformated for bugzilla) goes like this:
MCSymbol *Sym = getContext().GetOrCreateSymbol(Split.first);
...
MCSymbolRefExpr::VariantKind Variant =
MCSymbolRefExpr::getVariantKindForName(Split.second);
if (Variant == MCSymbolRefExpr::VK_Invalid)
{
Variant = MCSymbolRefExpr::VK_None;
return TokError("invalid variant '" + Split.second + "'");
}
....
Problem is when stdcall function on wincoff gets called from assembly with
similar assembly line: calll *_GetTickCount at 0, the '0' after '@' will
obviously cause VK_Invalid to be set on Variant, user gets:
... invalid variant '0'.
I propose to add a reference to MCAsmInfo to AsmParser, initialize it in
constructor and add check for MAI.hasMicrosoftFastStdCallMangling() to
AsmParser::ParsePrimaryExpr, then call GetOrCreateSymbol on whole Identifier
without splitting it around '@' for wincoff case.
I can send patch for revision in around 10 hours. I can then try to support
with extensions for cc1as for Wincoff (1 .section doesnt get parsed, 2 zerofill
from coffasmparser causes llvm_unreachable).
What do You guys think of proposed change?
Regards,
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the llvm-bugs
mailing list