[llvm-commits] [patch] Add TLS hook to MCTargetExpr (AArch64 generic change)
Tim Northover
Tim.Northover at arm.com
Tue Jan 15 01:19:40 PST 2013
Hi all,
Any more comments on this? Can I commit it? Should I fold it back into the
AArch64 patch so that it goes in with motivation?
Cheers.
Tim.
On Thursday 10 Jan 2013 15:15:25 Tim Northover wrote:
> On Wednesday 09 Jan 2013 19:02:07 Tim Northover wrote:
> > > No objection per se, but it'd be nice to see the cleanups in at least
> > > one target as the motivation for the change?
> >
> > Fair enough. I'll work on porting the ARM target tomorrow.
>
> Hmm. This turned out to be more difficult than anticipated. Unlike the
> AArch64 backend, the ARM one uses a combination of MCFixup kinds and
> MCSymbolRef kinds to determine the correct relocation in
> ARMELFObjectWriter (AArch64 uses different fixups only).
>
> Unfortunately, the TargetMCExprs seem to have been discarded by this point
> (only an MCSymbolRefExpr is available in MCValue). A messy but small
> problem for instructions, but a larger one for constant pool entries,
> which always seem to get FK_Data_4 (or similar) MCFixup kind.
>
> An alternative viewpoint is that without this patch we're adopting the view
> that TargetMCExpr's cannot contain any TLS symbols via any means. Obviously
> I don't agree with that.
>
> I've put the AArch64 implementation of this new callback at the end of this
> message to show some kind of motivation. I've also attached the incomplete
> ARM conversion: it's completely broken for object file output for the
> reasons mentioned above (ignore ARMELFObjectWriter in particular), but
> gives some idea of the kind of backend changes I'm talking about.
>
> Tim.
>
> ---------------------------------
>
> static void fixELFSymbolsInTLSFixupsImpl(const MCEXpr *Expr, MCAssembler
> &Asm);
>
> void AArch64MCExpr::fixELFSymbolsInTLSFixups(MCAssembler &Asm) const {
> switch (getKind()) {
> default:
> return;
> case VK_AARCH64_DTPREL_G2:
> case VK_AARCH64_DTPREL_G1:
> case VK_AARCH64_DTPREL_G1_NC:
> case VK_AARCH64_DTPREL_G0:
> case VK_AARCH64_DTPREL_G0_NC:
> case VK_AARCH64_DTPREL_HI12:
> case VK_AARCH64_DTPREL_LO12:
> case VK_AARCH64_DTPREL_LO12_NC:
> case VK_AARCH64_GOTTPREL_G1:
> case VK_AARCH64_GOTTPREL_G0_NC:
> case VK_AARCH64_GOTTPREL:
> case VK_AARCH64_GOTTPREL_LO12:
> case VK_AARCH64_TPREL_G2:
> case VK_AARCH64_TPREL_G1:
> case VK_AARCH64_TPREL_G1_NC:
> case VK_AARCH64_TPREL_G0:
> case VK_AARCH64_TPREL_G0_NC:
> case VK_AARCH64_TPREL_HI12:
> case VK_AARCH64_TPREL_LO12:
> case VK_AARCH64_TPREL_LO12_NC:
> case VK_AARCH64_TLSDESC:
> case VK_AARCH64_TLSDESC_LO12:
> break;
> }
>
> fixELFSymbolsInTLSFixupsImpl(getSubExpr(), Asm);
> }
>
>
> static void fixELFSymbolsInTLSFixupsImpl(const MCExpr *Expr, MCAssembler
> &Asm) {
> switch (Expr->getKind()) {
> case MCExpr::Target:
> llvm_unreachable("Can't handle nested target expression");
> break;
> case MCExpr::Constant:
> break;
>
> case MCExpr::Binary: {
> const MCBinaryExpr *BE = cast<MCBinaryExpr>(Expr);
> fixELFSymbolsInTLSFixupsImpl(BE->getLHS(), Asm);
> fixELFSymbolsInTLSFixupsImpl(BE->getRHS(), Asm);
> break;
> }
>
> case MCExpr::SymbolRef: {
> // We're known to be under a TLS fixup, so any symbol should be
> // modified. There should be only one.
> const MCSymbolRefExpr &SymRef = *cast<MCSymbolRefExpr>(Expr);
> MCSymbolData &SD = Asm.getOrCreateSymbolData(SymRef.getSymbol());
> MCELF::SetType(SD, ELF::STT_TLS);
> break;
> }
>
> case MCExpr::Unary:
> fixELFSymbolsInTLSFixupsImpl(cast<MCUnaryExpr>(Expr)->getSubExpr(),
> Asm); break;
> }
> }
-------------- next part --------------
A non-text attachment was scrubbed...
Name: target-tls-hook.diff
Type: text/x-patch
Size: 1854 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130115/d1b2c47c/attachment.bin>
More information about the llvm-commits
mailing list