[LLVMdev] Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo

Fri May 22 16:08:52 PDT 2015

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.

> On May 22, 2015, at 11:49 AM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote:
> 
> > Why isn't the ABI reflected in the triple?
> 
> 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 toolchains 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, when given the -EL option, mips-linux-gnu will produce little endian binaries despite having a big-endian triple. 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.
> 
> 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.
> There's an ARM example of the same problem at https://wiki.debian.org/Multiarch/Tuples#Why_not_use_GNU_triplets.3F <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.
> 
> 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.

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.

> 
> > Can you thread whatever selects the object file into down to whatever selects the asm info?
> 
> 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.
> 
> 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.
>  
> From: <> Reid Kleckner [mailto:rnk at google.com] 
> Sent: 22 May 2015 16:22
> To: Daniel Sanders
> Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu)
> Subject: Re: [LLVMdev] Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo
>  
> 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".
>  
> 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?
>  
> Maybe MCAsmInfo should be completely folded into MCObjectFileInfo, or renamed if it no longer describes "assembly" information.
>  
> Anyway, this one change seems fine by itself. I'm mostly pointing out that this area needs a bit of cleanup.
>  
> On Thu, May 21, 2015 at 8:40 AM, Daniel Sanders <Daniel.Sanders at imgtec.com <mailto:Daniel.Sanders at imgtec.com>> wrote:
> Hi,
>  
> 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.
>  
> 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
> 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.
>  
> Does anyone agree/disagree with this change? Have I missed anything?
>  
> Daniel Sanders
> Leading Software Design Engineer, MIPS Processor IP
> Imagination Technologies Limited
> www.imgtec.com <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=>
>  
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>         http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>  
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150522/f85a82e2/attachment.html>