[LLVMdev] [MC] [llvm-mc] Getting target specific information to <target>ELFObjectWriter

Carter, Jack jcarter at mips.com
Mon Dec 17 15:17:18 PST 2012


Eli,

Yes, SubtargetInfo is more of a container of convenience since it is available to all the assemblers.  Working with the current framework it seemed the least disruptive. 

I'll describe the problem again.

The Mips ABI for better or worse, uses the ELF headers e_flags extensively. The most pressing issue is the need to post the relocation model such as PIC, CPIC or non-shared. The object method that allows me to update the e_flags at the target level, <target>ELFObjectWriter::getEFlags(),  had no access to any target specific information . 

MipsELFObjectWriter is created during MipsAsmBackend construction which is create during an invocation of createMipsAsmBackend().

create<target>AsmBackend is called by:
  the codegen (integrated assembler)
  llvm-mc (standalone assembler)
  clang (cc1as_main.cpp)

My solution for getting access of target specific data to <target>ELFObjecWriter was to pass a reference of SubtargetInfo to it through the <target>AsmBackend construction.

For the integrated assembler this works well because what is really passed is a derived class of <target>Subtarget. I can add stuff to MipsSubtarget without affecting any other target. Here is the inheritance: 
  SubtargetInfo
  TargetSubtargetInfo
  <target>GenSubtargetInfo
  <target>Subtarget

<target>Subtarget is created through TargetMachine and is codegen centric. 

For the standalone assembler and the clang this isn't the case. A straight SubtargetInfo object is created.

>From here I added a single data member to the SubratgetInfo class that could be used as a message board so when one is in a method like MipsELFObjectWriter::getEFlags() one could access the information in a common manner.

I made the message board a set with the tag being an integer so each target which chooses to use it could create their own enumerations for the stored info. My initial thought was to make it a set of ints because I just wanted to know if things were on or off, but maybe a set of pointers to templated unions would be more flexible although I do believe that this is overkill.

Cheers,

Jack

________________________________________
From: Eli Bendersky [eliben at google.com]
Sent: Friday, December 14, 2012 4:26 PM
To: Carter, Jack
Cc: Jim Grosbach; List
Subject: Re: [LLVMdev] [MC] [llvm-mc] Getting target specific information to <target>ELFObjectWriter

On Fri, Dec 14, 2012 at 1:03 PM, Carter, Jack <jcarter at mips.com> wrote:
> Eli,
>
> This is the kind of feedback I want. I believe I have to add to the base class so it should be generally useful. I can see string being better for the value. I still am enamoured with an enumeration for the tab though: int->string. How would that be a limitation?
>

I guess that's fine, as long as you don't just limit it to binary "has
/ hasn't flag".

> How about the rest of the patch?
>

There's one thing about it I'm not sure I understand. You are
essentially passing commands to the assembler via "target"
information. But how does this make sense? I realize that the flags
themselves (their kinds and possible values) are properties of the
target, but their passing to the assembler is not. In other words, I
would expect the assembler driver to propagate flags down to the ELF
writer in some manner which is not through the target object. The
target object is supposed to provide information about the target,
which does not depend on the particular invocation of the assembler
and the flags passed to it.

I hope the above is coherent; it not, feel free to demand another attempt.

Eli




More information about the llvm-dev mailing list