Daniel: Thanks for your detailed response. I had seen the discussion from earlier this year, but when I read it, I didn't expect it would be so difficult to get just one bit of information where I wanted it. 
Thanks for the heads up about clang not necessarily setting ABIname. I have at least enough of that working already that I can generate the appropriate assembly source.
After doing a little more investigation, I decided to take an approach that seems simpler than yours, as I'm only trying to solve my own problem. It relies on having things lower in the MC layer be able to query MCTargetOptions. This is my plan:
Make a path from the callers of Target::createAsmBackend to get MCTargetOptions to the MCELFObjectTargetWriter subclass or some method in the creation chain:
<client, e.g. llvm-mc>
-> Target::createAsmBackend(..., MCTargetOptions)
-> (*MCAsmBackendCtorFn)(..., MCTargetOptions)
-> <MCAsmBackend subclass constructor wanting options>(..., MCTargetOptions)
adds MCTargetOptions to the MCAsmBackend subclass state or the bits needed
<MCAsmBackend subclass wanting options>::createObjectWriter(...)
-> create<foo>ObjectWriter(..., added information)
-> <foo>ObjectWriter::<foo>ObjectWriter(..., added information)
sets added state based on constructor args, in my case the ABI, IsILP32
<foo>ObjectWriter::GetRelocType(...)
use state to guide which relocations are generated
I don't know if the object lifetime of MCTargetOptions allows a reference to be kept around, so the information extraction in the MCAsmBackend subclass constructor may be required.
Anson
Hi Anson,
I've been working on similar problems in MIPS. We have several problems with the same root cause but the most relevant is that our N32 ABI implementation behaves too much like N64. We get lots of important N32 details wrong with one of the biggest being that we get the wrong EI_CLASS because we derive it from the triple and not the ABI (which is currently unavailable to the relevant object).
I have three patches that make a start on a general solution for this kind of problem (http://reviews.llvm.org/D13858, http://reviews.llvm.org/D13860, and http://reviews.llvm.org/D13863). The overall intent is that we create an MCTargetMachine that describes the desired target (taking into account the default ABI for the triple and any options that change it) and use it as a factory for the MC layer objects. This way we can pass relevant detail down to the MC objects without having to have all targets agree on what information should be provided to each object. This mechanism can then be extended to other target-specific detail as needed.
This mechanism also provides the groundwork to solve the Triple ambiguity problem (see http://lists.llvm.org/pipermail/llvm-dev/2015-July/087700.html) that most targets have to some degree but ARM and MIPS particularly suffer from. This problem isn't limited to the MC layer, it also causes problems with CodeGen and compatibility with GCC (differences in default option values, etc.).
My work in this area has been in review in since July and there have been no commits yet so I've recently been considering adding MCTargetOptions to some of the createMC*() functions as stop-gap measure to get some of the bugs fixed sooner. I'll still need to fix the triple ambiguity problem properly to avoid releasing multiple single-target clang toolchains (which I'm very keen to avoid doing but I don't have much choice as things stand) but it at least lets me improve matters.
By the way, you'll find that some paths through clang use the default constructor of MCTargetOptions and therefore neglect to set MCTargetOptions::ABIName. I was planning to fix this once I had the backend side of things working.
Should I make up a new OSABI enum value? Do some kind of manipulation of the Triple environment field to set it based upon the value of "-mabi="?
Both of those approaches would work and are similar to Debian's concept of Multiarch Tuples.
My original TargetTuple solution was somewhat similar in principle but unfortunately was not accepted. In the TargetTuple solution, I was trying to introduce a boundary between the world of GNU Triples and the world of LLVM Target Descriptions. At the moment llvm::Triple is responsible for interpreting GNU Triples and being a target description within LLVM. So in the TargetTuple solution, llvm::Triple parsed the triple and was then used to initialize a more detailed, unambiguous, and authoritative target description in llvm::TargetTuple. Command line arguments then modified the TargetTuple after which it was passed to the backend instead of llvm::Triple.
It will be interesting to see what answers you get here. Personally, I was avoiding inventing values in the llvm::Triple enums because MIPS needs to convey information that is only implied by the triple (and therefore needed new member variables) and/or differs between linux distributions, and also because I thought that separating the GNU Triple parser and the resulting target description was a good thing to do. However, if there's some agreement that this is the right thing to do then I can rethink my plan and find some way to encode what I need in one of these fields.