<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style>
<!--
@font-face
{font-family:Calibri}
@font-face
{font-family:Tahoma}
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
{color:blue;
text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{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
{font-family:"Calibri","sans-serif";
color:windowtext}
span.SpellE
{}
.MsoChpDefault
{font-family:"Calibri","sans-serif"}
@page WordSection1
{margin:72.0pt 72.0pt 72.0pt 72.0pt}
div.WordSection1
{}
-->
</style><style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1" style="" lang="EN-GB" link="blue" vlink="purple">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">
<div class="WordSection1"><font size="2">> Why isn't the ABI reflected in the triple?<br>
<br>
Unfortunately, there's no easy answer to that. Some targets are better than others but generally speaking triples are very ambiguous. For example, in (most) GCC mips-linux-gnu/mips64-linux-gnu
</font><font size="2"><font size="2">toolchains </font>both triples produce 32-bit big-endian binaries for MIPS-I by default. Vendors can override the majority of this so it's entirely possible for mips-foo-linux-gnu to produce 64-bit little endian binaries
for Mips64r6 by default. Additionally, w</font><font size="2"><font size="2">hen given the -EL option, mips-linux-gnu will produce little endian binaries despite having a big-endian triple.
</font>The same applies to a lot of our code generation options. The most complicated one I'm aware of is mips-mti-linux-gnu which can produce code for nearly any Mips target when given the right options.<br>
<br>
The main issue I have at the moment is with the N32 and N64 ABI's. These are ILP32 and LP64 respectively, are mutually incompatible, and have traditionally used the same triple.<br>
There's an ARM example of the same problem at https://wiki.debian.org/Multiarch/Tuples#Why_not_use_GNU_triplets.3F. In that example, hard-float and soft-float both used arm-linux-gnueabi but were mutually incompatible. The Multiarch tuples described on that
page are an attempt to resolve the ambiguity but I'm told that they aren't likely to be universally adopted.<br>
<br>
Maybe, a better solution is to have a clean break from traditional triples and have a translation layer to convert traditional triples into a new set of unambiguous LLVM tuples. Ideally, frontends wouldn't have to worry too much about the details of this and
can just set some options for the target and be told the correct LLVM tuple to use.<br>
<br>
> Can you thread whatever selects the object file into down to whatever selects the asm info?<br>
<br>
Sorry about this. I'm working on two very similar issues at the same time (this one and the exception TType encoding being ABI dependant) and I've mixed them together in my original email. The split I should have described is that the label prefix is '$' for
O32 and '.L' for N32/N64. Unfortunately O32/N32 are ELF32 and N64 is ELF64.<br>
<br>
I tried passing MCTargetOptions::ABIName down to the MCAsmInfo but ran into problems with some users of MCAsmInfo not initializing MCTargetOptions. There is also a problem with some users of MCAsmInfo not knowing the ABI. For example, llvm-objdump doesn't know
the ABI until it starts reading the object file but has to initialize the MCAsmInfo earlier than that. IRObjectFile was another problem area.<br>
</font>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif""> </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"><a name="_MailOriginal"><b><span style="font-size:10.0pt; font-family:"Tahoma","sans-serif"" lang="EN-US">From:</span></b></a><span style=""><span style="font-size:10.0pt; font-family:"Tahoma","sans-serif"" lang="EN-US"> Reid Kleckner [mailto:rnk@google.com]
<br>
<b>Sent:</b> 22 May 2015 16:22<br>
<b>To:</b> Daniel Sanders<br>
<b>Cc:</b> LLVM Developers Mailing List (llvmdev@cs.uiuc.edu)<br>
<b>Subject:</b> Re: [LLVMdev] Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo</span></span></p>
</div>
</div>
<p class="MsoNormal"><span style=""> </span></p>
<div>
<p class="MsoNormal"><span style="">I think MCAsmInfo was really intended to describe this kind of stuff in the first place. The way I understand it, it's supposed to describe things like "what are the quirks of this target's assembler that I need to know",
which includes the private label prefix. That said, it grew lots of other unrelated responsibilities, like "how does EH work on this target".</span></p>
<div>
<p class="MsoNormal"><span style=""> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="">Why isn't the ABI reflected in the triple? Can you thread whatever selects the object file into down to whatever selects the asm info?</span></p>
</div>
<div>
<p class="MsoNormal"><span style=""> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="">Maybe MCAsmInfo should be completely folded into MCObjectFileInfo, or renamed if it no longer describes "assembly" information.</span></p>
</div>
<div>
<p class="MsoNormal"><span style=""> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="">Anyway, this one change seems fine by itself. I'm mostly pointing out that this area needs a bit of cleanup.</span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style=""> </span></p>
<div>
<p class="MsoNormal"><span style="">On Thu, May 21, 2015 at 8:40 AM, Daniel Sanders <</span><a href="mailto:Daniel.Sanders@imgtec.com" target="_blank"><span style="">Daniel.Sanders@imgtec.com</span><span style=""></span></a><span style="">> wrote:</span></p>
<div>
<div>
<p class="MsoNormal" style=""><span style="">Hi,</span></p>
<p class="MsoNormal" style=""><span style=""> </span></p>
<p class="MsoNormal" style=""><span style="">I've been having trouble properly resolving an issue with our assembly syntax. The prefix our assembler uses for private local/global labels depends on the object file format. For ELF32 they begin with '$' and for
ELF64 they begin with '.L'. The object file format depends on the ABI, but multiple ABI's are usable with the same target triple so we can't select between the prefixes using triples. In the current structure, we appear to need MCAsmInfo to return different
values for different object formats but it has no means to do this.</span></p>
<p class="MsoNormal" style=""><span style=""> </span></p>
<p class="MsoNormal" style=""><span style="">It seems to me that the private label prefixes are more closely associated with the object file format than they are with the assembly syntax so I'd like to propose moving
</span></p>
<p class="MsoNormal" style=""><span style="">MCAsmInfo::getPrivateGlobalPrefix(), MCAsmInfo::getPrivateLabelPrefix(), and MCAsmInfo::getLinkerPrivateGlobalPrefix() to MCObjectFileInfo and its subclasses. This fixes the Mips case and should have no noticeable
impact on other targets. ARM will need some new MCObjectFileInfo classes to handle COFF but other than that, the change seems fairly simple.</span></p>
<p class="MsoNormal" style=""><span style=""> </span></p>
<p class="MsoNormal" style=""><span style="">Does anyone agree/disagree with this change? Have I missed anything?</span></p>
<p class="MsoNormal" style=""><span style=""> </span></p>
<p class="MsoNormal" style="text-align:justify"><span style=""><b><span style="font-family:"Arial","sans-serif"; color:#3333FF">Daniel Sanders</span></b></span></p>
<p class="MsoNormal" style="text-align:justify"><span style=""><span style="font-size:10.0pt; font-family:"Arial","sans-serif"; color:#3333FF">Leading Software Design Engineer, MIPS Processor IP</span></span></p>
<p class="MsoNormal" style="text-align:justify"><span style=""><span style="font-size:10.0pt; font-family:"Arial","sans-serif"; color:#3333FF">Imagination Technologies Limited</span></span></p>
<p class="MsoNormal" style="text-align:justify"><span style=""></span><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.imgtec.com_&d=AwMFAg&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=zfZRQGD_5uNPepX1eAkaBGbEPGddM5b_p16e7gchhmA&s=jcHeVUlAAMi_-CIYlWvRUYcfRKFShMSHzLBBZFz7FYI&e=" target="_blank"><span style=""><span style="font-size:10.0pt; font-family:"Arial","sans-serif"">www.imgtec.com</span></span><span style=""></span></a><span style=""></span></p>
<p class="MsoNormal" style=""><span style=""> </span></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style=""><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
</span><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank"><span style="">LLVMdev@cs.uiuc.edu</span><span style=""></span></a><span style=""> </span><a href="http://llvm.cs.uiuc.edu" target="_blank"><span style="">http://llvm.cs.uiuc.edu</span><span style=""></span></a><span style=""><br>
</span><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank"><span style="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</span><span style=""></span></a><span style=""></span></p>
</div>
<span style=""></span>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</body>
</html>