[LLVMdev] Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo

Reid Kleckner rnk at google.com
Fri May 22 08:21:36 PDT 2015


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>
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         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/29405c10/attachment.html>


More information about the llvm-dev mailing list