This is an archive of the discontinued LLVM Phabricator instance.

MC asm parser: allow @'s in symbol names in MS assembly
ClosedPublic

Authored by hans on Oct 18 2013, 11:32 AM.

Details

Summary

This is another (final?) stab at making us able to parse our own asm output.

On Windows, it's not uncommon to have @'s and ?'s show up in symbol names. Our parser didn't like this. The ?'s were rejected, and the @'s were interpreted as trying to reference something like PLT or GOT.

My previous solution of quoting these names didn't work, as for some targets we use the gas assembler, which doesn't like quotes in certain places (most notably in .def directives).

Instead, I think we should try to parse these symbol names without quotes, as gas does.

This is probably not perfect, but should allow us to start being able to parse our asm output on windows.

Diff Detail

Event Timeline

majnemer added inline comments.Oct 18 2013, 11:37 AM
lib/MC/MCParser/AsmParser.cpp
2129

Should this be gated on doesAllowAtInName?

hans added inline comments.Oct 18 2013, 11:55 AM
lib/MC/MCParser/AsmParser.cpp
2129

I don't know, we already allow @'s in names during parsing. This just allows them as the initial character, and I don't think this introduces any ambiguity.

The doesAllowAtInName() is more like "is the @ part of the name for realz, or does it signify the separator between the name and PLT/GOT/etc".

If we gate it here, we'd have to gate it in the switch in parsePrimaryExpr() too.

Do we already have a testcase showing that we reject foo@bar on ELF? If not, it would be a good idea to add one.

lib/MC/MCParser/AsmLexer.cpp
143

adding support for ? in a name can be an independent change, no?

btw, on linux gas rejects

.globl foo?bar

Should be reject too? I am tempted to just accept it everywhere as an extension, since it doesn't look ambiguous (unlike the @)

hans added a comment.Oct 18 2013, 12:10 PM

Do we already have a testcase showing that we reject foo@bar on ELF? If not, it would be a good idea to add one.

We don't. I'll add one.

lib/MC/MCParser/AsmLexer.cpp
143

Right, this would be an extension, and like you say I think it would be harmless - I don't think the lexer actually accepts in anywhere else.

gas doesn't accept this, but these symbols should not be showing up in asm the we send to gas.

I could do this in an independent change, but I think it ties in nicely with the test I'm adding here. Happy to split it out if you think it's important though.

hans updated this revision to Unknown Object (????).Oct 18 2013, 12:12 PM

Add another test.

I could do this in an independent change, but I think it ties in nicely with the test I'm adding here. Happy to split it out if you think it's important though.

Nah, it is fine. Just add a test showing we accept in on ELF too with
a comment saying it is an extension.

Cheers,
Rafael

hans closed this revision.Oct 18 2013, 1:50 PM

Closed by commit rL193000 (authored by @hans).