<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div>ARM already has a similar problem, where the prefix on Darwin is not the same as it is on Linux. It sounds like your situation is a bit more complicated, though.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class="">On May 22, 2015, at 11:49 AM, Daniel Sanders <<a href="mailto:Daniel.Sanders@imgtec.com" class="">Daniel.Sanders@imgtec.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; direction: ltr; font-family: Tahoma; font-size: 10pt;" class=""><div class="WordSection1"><font size="2" class="">> Why isn't the ABI reflected in the triple?<br class=""><br class="">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<span class="Apple-converted-space"> </span></font><font size="2" class=""><font size="2" class="">toolchains<span class="Apple-converted-space"> </span></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" class=""><font size="2" class="">hen given the -EL option, mips-linux-gnu will produce little endian binaries despite having a big-endian triple.<span class="Apple-converted-space"> </span></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 class=""><br class="">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 class="">There's an ARM example of the same problem at<span class="Apple-converted-space"> </span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.debian.org_Multiarch_Tuples-23Why-5Fnot-5Fuse-5FGNU-5Ftriplets.3F&d=AwMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=o79f4knApxh4Bc0uP-2ssYD6otmJuPAYyjhgALF-Ry8&s=4f_gRd7qMxVzZnIp0EvLxjgdLtTunWaMdfyOdqH8VVg&e=" style="color: purple; text-decoration: underline;" class="">https://wiki.debian.org/Multiarch/Tuples#Why_not_use_GNU_triplets.3F</a>. 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 class=""><br class="">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 class=""></font></div></div></div></blockquote><div><br class=""></div><div><br class=""></div>This is the key question. The LLVM assumption is that these sorts of things are inferable from the triple. Your observation here that the GNU world’s notion of triples and LLVM’s need not be the same is a good one. Having a split and a translation up in clang seems an interesting avenue to explore. I suspect this won’t be the last of this sort of issue you’ll encounter, unfortunately. Smarter LLVM layer triples is very worth exploring. Darwin puts things like deployment target version numbers in the triple (arm64-apple-ios8.3, e.g.). Having something to distinguish between ELF32 vs. ELF64, or whatever else, be explicit in the LLVM triple seems reasonable.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; direction: ltr; font-family: Tahoma; font-size: 10pt;" class=""><div class="WordSection1"><font size="2" class=""><br class="">> Can you thread whatever selects the object file into down to whatever selects the asm info?<br class=""><br class="">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 class=""><br class="">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 class=""></font><p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><span style="font-size: 11pt; font-family: Calibri, sans-serif;" class=""> </span></p><div style="border-style: none none none solid; border-left-color: blue; border-left-width: 1.5pt; padding: 0cm 0cm 0cm 4pt;" class=""><div class=""><div style="border-style: solid none none; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0cm 0cm;" class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><a name="_MailOriginal" class=""><b class=""><span lang="EN-US" style="font-size: 10pt; font-family: Tahoma, sans-serif;" class="">From:</span></b></a><span class=""><span lang="EN-US" style="font-size: 10pt; font-family: Tahoma, sans-serif;" class=""><span class="Apple-converted-space"> </span>Reid Kleckner [<a href="mailto:rnk@google.com" class="">mailto:rnk@google.com</a>]<span class="Apple-converted-space"> </span><br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>22 May 2015 16:22<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span>Daniel Sanders<br class=""><b class="">Cc:</b><span class="Apple-converted-space"> </span>LLVM Developers Mailing List (<a href="mailto:llvmdev@cs.uiuc.edu" class="">llvmdev@cs.uiuc.edu</a>)<br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>Re: [LLVMdev] Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo</span></span></div></div></div><p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><span class=""> </span></p><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span class="">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></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><span class=""> </span></p></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span class="">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></div></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><span class=""> </span></p></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span class="">Maybe MCAsmInfo should be completely folded into MCObjectFileInfo, or renamed if it no longer describes "assembly" information.</span></div></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><span class=""> </span></p></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span class="">Anyway, this one change seems fine by itself. I'm mostly pointing out that this area needs a bit of cleanup.</span></div></div></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><span class=""> </span></p><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span class="">On Thu, May 21, 2015 at 8:40 AM, Daniel Sanders <</span><a href="mailto:Daniel.Sanders@imgtec.com" target="_blank" style="color: purple; text-decoration: underline;" class=""><span class="">Daniel.Sanders@imgtec.com</span><span class=""></span></a><span class="">> wrote:</span></div><div class=""><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span class="">Hi,</span></div><p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><span class=""> </span></p><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span class="">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></div><p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><span class=""> </span></p><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span class="">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></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span class="">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></div><p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><span class=""> </span></p><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span class="">Does anyone agree/disagree with this change? Have I missed anything?</span></div><p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><span class=""> </span></p><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; text-align: justify;" class=""><span class=""><b class=""><span style="font-family: Arial, sans-serif; color: rgb(51, 51, 255);" class="">Daniel Sanders</span></b></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; text-align: justify;" class=""><span class=""><span style="font-size: 10pt; font-family: Arial, sans-serif; color: rgb(51, 51, 255);" class="">Leading Software Design Engineer, MIPS Processor IP</span></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; text-align: justify;" class=""><span class=""><span style="font-size: 10pt; font-family: Arial, sans-serif; color: rgb(51, 51, 255);" class="">Imagination Technologies Limited</span></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; text-align: justify;" class=""><span class=""></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" style="color: purple; text-decoration: underline;" class=""><span class=""><span style="font-size: 10pt; font-family: Arial, sans-serif;" class="">www.imgtec.com</span></span><span class=""></span></a><span class=""></span></div><p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><span class=""> </span></p></div></div><p class="MsoNormal" style="margin: 0cm 0cm 12pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><span class=""><br class="">_______________________________________________<br class="">LLVM Developers mailing list<br class=""></span><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank" style="color: purple; text-decoration: underline;" class=""><span class="">LLVMdev@cs.uiuc.edu</span><span class=""></span></a><span class=""> </span><a href="http://llvm.cs.uiuc.edu/" target="_blank" style="color: purple; text-decoration: underline;" class=""><span class="">http://llvm.cs.uiuc.edu</span><span class=""></span></a><span class=""><br class=""></span><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" style="color: purple; text-decoration: underline;" class=""><span class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</span><span class=""></span></a><span class=""></span></p></div><span class=""></span><p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;"> </p></div></div></div></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">LLVM Developers mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><a href="mailto:LLVMdev@cs.uiuc.edu" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" class="">http://llvm.cs.uiuc.edu</a></span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></span></div></blockquote></div><br class=""></body></html>