<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1" style="word-wrap:break-word">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Jim,<br>
<br>
Happy new year.<br>
<br>
I still need to pass ELF e_header information somehow to MipsELFObjectWriter. This includes the relocation model the chip level and any processor extensions along with xgot use.
<br>
<br>
I don't see any target, including ARM, doing what I need here. How do I get this information accessible to MipsELFObjectWriter? My patch does this, but I will take another path if it works.<br>
<br>
As an experiment I exported MCObjectWriter and created an accessor method to hand over a pointer to MCELFObjectTargetWriter which can be cast to MipsELFObjectWriter. This works fine and doesn't require MCSubtargetInfo at all, but I fear that exposing the declarations
in lib/MC/ELFObjectWriter is a non-starter. I'll attach a sample patch for reference.<br>
<br>
In the case of my MCSubtargetInfo patch, I don't see where there is a place for all of the information I need. We don't store the relocation model (PIC/CPIC/STATIC) there nor in the features list. Thus the new data member.<br>
<br>
This has to work for both llc and llvm-mc.<br>
<br>
Regards,<br>
<br>
Jack<br>
<br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF465848"><font color="#000000" face="Tahoma" size="2"><b>From:</b> Jim Grosbach [grosbach@apple.com]<br>
<b>Sent:</b> Friday, December 21, 2012 4:01 PM<br>
<b>To:</b> Carter, Jack<br>
<b>Cc:</b> llvm-commits@cs.uiuc.edu<br>
<b>Subject:</b> Re: [PATCH] review request: [MC] [llvm-mc] Getting target specific information to <target>ELFObjectWriter<br>
</font><br>
</div>
<div></div>
<div>Hi Jack,
<div><br>
</div>
<div>There is no such class as "SubtargetInfo". There is MCSubtargetInfo and TargetSubtargetInfo. Please be very, very careful to indicate which you're talking about. The distinction is not arbitrary.</div>
<div><br>
</div>
<div>As to the additional data member, I'm unconvinced it's necessary. Targets already do target-specific things with regards to the object file writers (ARM, for example).</div>
<div><br>
</div>
<div>Likewise, why does the ELFObjectWriter need the MCSubtargetInfo? Any sub target information is, by definition, target specific and should already be available to the backend (assembler or compiler) whenever the object writer needs such information. For
a rough example on the compiler side, ARMAsmPrinter::emitAttributes().</div>
<div><br>
</div>
<div>-Jim</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
<div>
<div>On Dec 21, 2012, at 3:07 PM, "Carter, Jack" <<a href="mailto:jcarter@mips.com" target="_blank">jcarter@mips.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="font-family:Helvetica; font-size:medium; font-style:normal; font-variant:normal; font-weight:normal; letter-spacing:normal; line-height:normal; orphans:2; text-indent:0px; text-transform:none; white-space:normal; widows:2; word-spacing:0px">
<div style="direction:ltr; font-family:Tahoma; font-size:10pt">
<div style="font-family:'Times New Roman'; font-size:16px"><br>
SUMMARY:<br>
<div>
<div style="direction:ltr; font-family:Tahoma; font-size:10pt">This patch adds the SubtargetInfo class<span class="Apple-converted-space"> </span><br>
object to the creation of the <target>MCAsmBackend<br>
class object.<br>
<br>
PROBLEM:<br>
The problem I have been having for some time is how<br>
to get access to target specific information during<br>
the direct object output phase. The current issue was<br>
how to fill the ELF header's target specific E_FLAGS<br>
bit field.<br>
<br>
SOLUTION:<br>
The information has already been collected and isolated<br>
by the SubtargetInfo class object. This patch<br>
passes the const reference to this class object to the<span class="Apple-converted-space"> </span><br>
<target>MCAsmBackend class object which in turn passes<span class="Apple-converted-space"> </span><br>
it to the <target>ELFObjectWriter class object which<br>
updates the E_FLAGS.<br>
<br>
This is the current creation routine for the backend:<br>
<br>
MCAsmBackend *llvm::createMipsAsmBackendEB64(const Target &T, StringRef TT,<br>
StringRef CPU,<br>
const SubtargetInfo *STI) {<br>
return new MipsAsmBackend(T, Triple(TT).getOS(),<br>
/*IsLittle*/false, /*Is64Bit*/true, STI);<br>
}<br>
<br>
I believe we could reduce this to the one parameter STI<span class="Apple-converted-space"> </span><br>
and derive the rest of the information from it. I also<br>
believe that STI could be used with the other MC classes<br>
to reduce the need for future parameters there as well.<br>
<br>
Since llc and llvm-mc use SubtargetInfo differently I have<br>
added a new data member to SubtargetInfo that is a set of<br>
integers for passing information. This data member may be<br>
extended to allow a set of unions so wome other object,<span class="Apple-converted-space"> </span><br>
but until there is a need for it, I want to keep it simple.<br>
<br>
The tags for the sets are target specific so what ARM would<br>
use it for would be different than for Mips if they want.<br>
<br>
CONCLUSION:<br>
* This patch does not affect the current behavior of other<br>
targets.<br>
* Future E_FLAGS additions will be easy to implement at the<br>
individual target level.<br>
* This change has changes in both the llvm and clang trees.<br>
<br>
<br>
Contributer: Jack Carter<br>
<br>
</div>
</div>
</div>
</div>
<span><elf_header.patch></span><span><elf_header_clang.patch></span></div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</body>
</html>