<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Hi Anson,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">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).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">I have three patches that make a start on a general solution for this kind of problem (<a href="http://reviews.llvm.org/D13858">http://reviews.llvm.org/D13858</a>,
<a href="http://reviews.llvm.org/D13860">http://reviews.llvm.org/D13860</a>, and <a href="http://reviews.llvm.org/D13863">
http://reviews.llvm.org/D13863</a>). 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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">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.).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">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="?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Both of those approaches would work and are similar to Debian's concept of Multiarch Tuples.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> llvm-dev [mailto:llvm-dev-bounces@lists.llvm.org]
<b>On Behalf Of </b>Anson MacDonald via llvm-dev<br>
<b>Sent:</b> 15 December 2015 22:58<br>
<b>To:</b> llvm-dev@lists.llvm.org<br>
<b>Subject:</b> [llvm-dev] How do I get ABI information to a subclass of MCELFObjectTargetWriter::GetLocType?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div id="yui_3_16_0_1_1450219359820_7409">
<div id="yui_3_16_0_1_1450219359820_7453">
<div id="yiv2724864838">
<div id="yui_3_16_0_1_1450219359820_7452">
<div id="yui_3_16_0_1_1450219359820_7451">
<div id="yiv2724864838yui_3_16_0_1_1450219359820_5009">
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">I am implementing a defined, but currently unimplemented by LLVM, ABI. This ABI differs from an existing ABI in its ELF object format
by implementing a subset of an existing ABI, but encoded differently and by setting the e_ident EI_CLASS field. I am trying to use MCTargetOptions::getABIName to set a boolean in the modified subclass of MCELFObjectTargetWriter to indicate which relocation
encoding to use. As far as I can determine by source examination and judicious use of a debugger there isn't a simple path from the command line and the setting of ABIname in MCTargetOptions to where an instance of a subclass of MCELFObjectTargetWriter is
created.</span><span style="font-family:"Helvetica","sans-serif";color:black"><o:p></o:p></span></p>
</div>
<div id="yiv2724864838yui_3_16_0_1_1450219359820_5043">
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222"><o:p> </o:p></span></p>
</div>
<div id="yiv2724864838yui_3_16_0_1_1450219359820_5047">
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">I looked at the approach taken by both Mips and X86 for implementing ILP32 and neither seems applicable. For x86 x32, there is the combination
of IsELF64 == false and OSABI == EM_X86_64, but that doesn't seem applicable, as the ELF e_machine field is the same for the existing and the new ABI. For Mips N32, code and state in MCELFObjectTargetWriter seems to take care of mapping the relocation values
and the ELF e_flags bit EF_MIPS_ABI_ON32 is set.<o:p></o:p></span></p>
</div>
<div id="yiv2724864838yui_3_16_0_1_1450219359820_5049">
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222"><o:p> </o:p></span></p>
</div>
<div id="yiv2724864838yui_3_16_0_1_1450219359820_5053">
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">I'm trying to implement the AArch64 ILP32 ELF ABI.Ideally, I'd like to be able to create a modified version of AArch64ELFObjectWriter
so that its GerRelocType method can choose which relocation encoding to use based upon what was specified on the command line. 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="?<o:p></o:p></span></p>
</div>
<div id="yiv2724864838yui_3_16_0_1_1450219359820_5055">
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222"><o:p> </o:p></span></p>
</div>
<div id="yiv2724864838yui_3_16_0_1_1450219359820_5059">
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">ARM64 ELF Reference with ILP32 information:<o:p></o:p></span></p>
</div>
<div id="yiv2724864838yui_3_16_0_1_1450219359820_5061">
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222"><a href="http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056c/IHI0056C_beta_aaelf64.pdf" target="_blank"><span style="color:#1155CC">http://infocenter.arm.com/
help/topic/com.arm.doc. ihi0056c/IHI0056C_beta_ aaelf64.pdf</span></a><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>