<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 18, 2015 at 3:22 AM Daniel Sanders <<a href="mailto:Daniel.Sanders@imgtec.com">Daniel.Sanders@imgtec.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That sounds like a good plan for your problem and I should be able to use it to fix a couple of the details in N32 such as private label prefixes.<br>
<br></blockquote><div><br></div><div>This is what I was suggesting to you originally.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Daniel: Thanks for your detailed response. I had seen the discussion from<br>
> earlier this year, but when I read it, I didn't expect it would be so difficult to<br>
> get just one bit of information where I wanted it. :-) Thanks for the heads up<br>
> about clang not necessarily setting ABIname. I have at least enough of that<br>
> working already that I can generate the appropriate assembly source.<br>
<br>
Glad I could help. I've been surprised by the difficulty of getting information in the right place too (and getting accurate information).<br>
<br>
> I don't know if the object lifetime of MCTargetOptions allows a reference to<br>
> be kept around, so the information extraction in the MCAsmBackend<br>
> subclass constructor may be required.<br>
<br>
It looks like MCTargetOptions do live long enough in LLVM's tools but I think that's a coincidence rather than the intent. It's probably best to take a copy in the MCAsmBackend.<br></blockquote><div><br></div><div>No, the intent is that things like TargetOptions and MCTargetOptions exist the life of the program.</div><div><br></div><div>-eric</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> -----Original Message-----<br>
> From: Anson MacDonald [mailto:<a href="mailto:anson_macdonald@yahoo.com" target="_blank">anson_macdonald@yahoo.com</a>]<br>
> Sent: 17 December 2015 17:07<br>
> To: Daniel Sanders; <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>; Eric Christopher<br>
> (<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>); Renato Golin (<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>)<br>
> Subject: Re: [llvm-dev] How do I get ABI information to a subclass of<br>
> MCELFObjectTargetWriter::GetLocType?<br>
><br>
> Daniel: Thanks for your detailed response. I had seen the discussion from<br>
> earlier this year, but when I read it, I didn't expect it would be so difficult to<br>
> get just one bit of information where I wanted it. :-) Thanks for the heads up<br>
> about clang not necessarily setting ABIname. I have at least enough of that<br>
> working already that I can generate the appropriate assembly source.<br>
><br>
><br>
> After doing a little more investigation, I decided to take an approach that<br>
> seems simpler than yours, as I'm only trying to solve my own problem. It<br>
> relies on having things lower in the MC layer be able to query<br>
> MCTargetOptions. This is my plan:<br>
><br>
> Make a path from the callers of Target::createAsmBackend to get<br>
> MCTargetOptions to the MCELFObjectTargetWriter subclass or some method<br>
> in the creation chain:<br>
><br>
> <client, e.g. llvm-mc><br>
>   -> Target::createAsmBackend(..., MCTargetOptions)<br>
>     -> (*MCAsmBackendCtorFn)(..., MCTargetOptions)<br>
>       -> <MCAsmBackend subclass constructor wanting options>(...,<br>
> MCTargetOptions)<br>
>          adds MCTargetOptions to the MCAsmBackend subclass state or the bits<br>
> needed<br>
> <MCAsmBackend subclass wanting options>::createObjectWriter(...)<br>
>   -> create<foo>ObjectWriter(..., added information)<br>
>     -> <foo>ObjectWriter::<foo>ObjectWriter(..., added information)<br>
>        sets added state based on constructor args, in my case the ABI, IsILP32<br>
> <foo>ObjectWriter::GetRelocType(...)<br>
>   use state to guide which relocations are generated<br>
><br>
> I don't know if the object lifetime of MCTargetOptions allows a reference to<br>
> be kept around, so the information extraction in the MCAsmBackend<br>
> subclass constructor may be required.<br>
><br>
> Anson<br>
> On Thursday, December 17, 2015 6:30 AM, Daniel Sanders<br>
> <<a href="mailto:Daniel.Sanders@imgtec.com" target="_blank">Daniel.Sanders@imgtec.com</a>> wrote:<br>
><br>
><br>
><br>
> Hi Anson,<br>
><br>
> I've been working on similar problems in MIPS. We have several problems<br>
> with the same root cause but the most relevant is that our N32 ABI<br>
> implementation behaves too much like N64. We get lots of important N32<br>
> details wrong with one of the biggest being that we get the wrong EI_CLASS<br>
> because we derive it from the triple and not the ABI (which is currently<br>
> unavailable to the relevant object).<br>
><br>
> I have three patches that make a start on a general solution for this kind of<br>
> problem (<a href="http://reviews.llvm.org/D13858" rel="noreferrer" target="_blank">http://reviews.llvm.org/D13858</a>, <a href="http://reviews.llvm.org/D13860" rel="noreferrer" target="_blank">http://reviews.llvm.org/D13860</a>,<br>
> and <a href="http://reviews.llvm.org/D13863" rel="noreferrer" target="_blank">http://reviews.llvm.org/D13863</a>). The overall intent is that we create an<br>
> MCTargetMachine that describes the desired target (taking into account the<br>
> default ABI for the triple and any options that change it) and use it as a<br>
> factory for the MC layer objects. This way we can pass relevant detail down<br>
> to the MC objects without having to have all targets agree on what<br>
> information should be provided to each object. This mechanism can then be<br>
> extended to other target-specific detail as needed.<br>
><br>
> This mechanism also provides the groundwork to solve the Triple ambiguity<br>
> problem (see <a href="http://lists.llvm.org/pipermail/llvm-dev/2015-" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2015-</a><br>
> July/087700.html) that most targets have to some degree but ARM and MIPS<br>
> particularly suffer from. This problem isn't limited to the MC layer, it also<br>
> causes problems with CodeGen and compatibility with GCC (differences in<br>
> default option values, etc.).<br>
><br>
> My work in this area has been in review in since July and there have been no<br>
> commits yet so I've recently been considering adding MCTargetOptions to<br>
> some of the createMC*() functions as stop-gap measure to get some of the<br>
> bugs fixed sooner. I'll still need to fix the triple ambiguity problem properly to<br>
> avoid releasing multiple single-target clang toolchains (which I'm very keen to<br>
> avoid doing but I don't have much choice as things stand) but it at least lets<br>
> me improve matters.<br>
><br>
> By the way, you'll find that some paths through clang use the default<br>
> constructor of MCTargetOptions and therefore neglect to set<br>
> MCTargetOptions::ABIName. I was planning to fix this once I had the<br>
> backend side of things working.<br>
><br>
> > Should I make up a new OSABI enum value? Do some kind of manipulation<br>
> of the Triple environment field to set it based upon the value of "-mabi="?<br>
><br>
> Both of those approaches would work and are similar to Debian's concept of<br>
> Multiarch Tuples.<br>
><br>
> My original TargetTuple solution was somewhat similar in principle but<br>
> unfortunately was not accepted. In the TargetTuple solution, I was trying to<br>
> introduce a boundary between the world of GNU Triples and the world of<br>
> LLVM Target Descriptions. At the moment llvm::Triple is responsible for<br>
> interpreting GNU Triples and being a target description within LLVM. So in<br>
> the TargetTuple solution, llvm::Triple parsed the triple and was then used to<br>
> initialize a more detailed, unambiguous, and authoritative target description<br>
> in llvm::TargetTuple. Command line arguments then modified the<br>
> TargetTuple after which it was passed to the backend instead of llvm::Triple.<br>
><br>
> It will be interesting to see what answers you get here. Personally, I was<br>
> avoiding inventing values in the llvm::Triple enums because MIPS needs to<br>
> convey information that is only implied by the triple (and therefore needed<br>
> new member variables) and/or differs between linux distributions, and also<br>
> because I thought that separating the GNU Triple parser and the resulting<br>
> target description was a good thing to do. However, if there's some<br>
> agreement that this is the right thing to do then I can rethink my plan and<br>
> find some way to encode what I need in one of these fields.<br>
><br>
> From:llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>] On Behalf Of Anson<br>
> MacDonald via llvm-dev<br>
> Sent: 15 December 2015 22:58<br>
> To: <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> Subject: [llvm-dev] How do I get ABI information to a subclass of<br>
> MCELFObjectTargetWriter::GetLocType?<br>
><br>
> I am implementing a defined, but currently unimplemented by LLVM, ABI.<br>
> This ABI differs from an existing ABI in its ELF object format by implementing<br>
> a subset of an existing ABI, but encoded differently and by setting the<br>
> e_ident EI_CLASS field. I am trying to use MCTargetOptions::getABIName to<br>
> set a boolean in the modified subclass of MCELFObjectTargetWriter to<br>
> indicate which relocation encoding to use. As far as I can determine by source<br>
> examination and judicious use of a debugger there isn't a simple path from<br>
> the command line and the setting of ABIname in MCTargetOptions to where<br>
> an instance of a subclass of MCELFObjectTargetWriter is created.<br>
><br>
> I looked at the approach taken by both Mips and X86 for implementing ILP32<br>
> and neither seems applicable. For x86 x32, there is the combination of<br>
> IsELF64 == false and OSABI == EM_X86_64, but that doesn't seem applicable,<br>
> as the ELF e_machine field is the same for the existing and the new ABI. For<br>
> Mips N32, code and state in MCELFObjectTargetWriter seems to take care of<br>
> mapping the relocation values and the ELF e_flags bit EF_MIPS_ABI_ON32 is<br>
> set.<br>
><br>
> I'm trying to implement the AArch64 ILP32 ELF ABI.Ideally, I'd like to be able<br>
> to create a modified version of AArch64ELFObjectWriter so that its<br>
> GerRelocType method can choose which relocation encoding to use based<br>
> upon what was specified on the command line. Should I make up a new<br>
> OSABI enum value? Do some kind of manipulation of the Triple environment<br>
> field to set it based upon the value of "-mabi="?<br>
><br>
> ARM64 ELF  Reference with ILP32 information:<br>
> <a href="http://infocenter.arm.com/" rel="noreferrer" target="_blank">http://infocenter.arm.com/</a> help/topic/com.arm.doc.<br>
> ihi0056c/IHI0056C_beta_ aaelf64.pdf<br>
</blockquote></div></div>