[llvm] r200051 - [Mips] TargetStreamer ELF flag Support for default and commandline options.

[Daniel Sanders]

Almost all of that makes sense to me. Thanks. The one bit that didn't make sense to me is below.

> Please note that from the MC point of view, all that you need to be able to
> parse are the directives that the mips codegen produces. You don't even
> need to be able to parse any real instructions (nop will do).

I'm surprised by the last sentence in particular. Surely the MC layer needs to be able to parse the instructions in codegens output for the same reason it needs to be able to parse the directives emitted by codegen. Partly to avoid assembly output being an unreliable debugging tool, and partly to be able to assemble to a desired object file.

> -----Original Message-----
> From: Rafael Espíndola [mailto:rafael.espindola at gmail.com]
> Sent: 27 January 2014 21:59
> To: Daniel Sanders
> Cc: Jack Carter; llvm-commits
> Subject: Re: [llvm] r200051 - [Mips] TargetStreamer ELF flag Support for
> default and commandline options.
> 
> ....
> > Just to clarify part of that objective. Should the assembly file be completely
> self-contained, or are command line arguments permitted to carry the initial
> state?
> 
> They have to be. The assembly files we use are the same that gas uses.
> So for example, for mips the abi is passed via a command line. The llvm-mc
> command line interface is *not* compatible, so there is some mapping
> involved. For example, -mips64 becomes -mcpu=mips64.
> 
> > The reason I ask is that I'm not 100% certain that the former is currently
> possible in all cases. For example, I'm fairly certain there is no directive
> equivalent to -mmsa in gas, although in this particular case we should
> definitely add one if it doesn’t already exist.
> 
> If it is passed to gas via a command line, it should probably be passed to llvm-
> mc via a command line too. If it is printed to the .s, it is a method in the
> streamer (or target streamer) interface.
> 
> > In my opinion, some (but by no means all) of it has its roots in our lack of
> need for an assembler other than gas. This is likely why we've been rather
> slow to implement the real directives and have continued to use the hack
> directive. That situation is changing. We have a couple projects lined up that
> will need a non-GPL assembler. We are in the very early stages of deciding
> exactly what features we need in this assembler, when, and how to achieve
> some of the trickier bits. It's naturally tempting to say that it should support
> all existing MIPS assembly but some historical behaviour of the assembler
> like instruction reordering (.setreorder) and the reserved scratch register
> (.setat) makes this harder than it sounds.
> 
> Please note that from the MC point of view, all that you need to be able to
> parse are the directives that the mips codegen produces. You don't even
> need to be able to parse any real instructions (nop will do).
> 
> Cheers,
> Rafael
> 
> To report this email as SPAM, please forward it to spam at websense.com