Files
llvm-6502/test/CodeGen/PowerPC
Ulrich Weigand 7a34599db0 [PowerPC] Revert r185476 and fix up TLS variant kinds
In the commit message to r185476 I wrote:

>The PowerPC-specific modifiers VK_PPC_TLSGD and VK_PPC_TLSLD
>correspond exactly to the generic modifiers VK_TLSGD and VK_TLSLD.
>This causes some confusion with the asm parser, since VK_PPC_TLSGD
>is output as @tlsgd, which is then read back in as VK_TLSGD.
>
>To avoid this confusion, this patch removes the PowerPC-specific
>modifiers and uses the generic modifiers throughout.  (The only
>drawback is that the generic modifiers are printed in upper case
>while the usual convention on PowerPC is to use lower-case modifiers.
>But this is just a cosmetic issue.)

This was unfortunately incorrect, there is is fact another,
serious drawback to using the default VK_TLSLD/VK_TLSGD
variant kinds: using these causes ELFObjectWriter::RelocNeedsGOT
to return true, which in turn causes the ELFObjectWriter to emit
an undefined reference to _GLOBAL_OFFSET_TABLE_.

This is a problem on powerpc64, because it uses the TOC instead
of the GOT, and the linker does not provide _GLOBAL_OFFSET_TABLE_,
so the symbol remains undefined.  This means shared libraries
using TLS built with the integrated assembler are currently
broken.

While the whole RelocNeedsGOT / _GLOBAL_OFFSET_TABLE_ situation
probably ought to be properly fixed at some point, for now I'm
simply reverting the r185476 commit.  Now this in turn exposes
the breakage of handling @tlsgd/@tlsld in the asm parser that
this check-in was originally intended to fix.

To avoid this regression, I'm also adding a different fix for
this problem: while common code now parses @tlsgd as VK_TLSGD,
a special hack in the asm parser translates this code to the
platform-specific VK_PPC_TLSGD that the back-end now expects.
While this is not really pretty, it's self-contained and
shouldn't hurt anything else for now.  One the underlying
problem is fixed, this hack can be reverted again.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185945 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-09 16:41:09 +00:00
..
2011-05-02 15:58:16 +00:00
2013-07-01 19:42:46 +00:00
2013-03-27 06:52:27 +00:00
2012-12-25 17:22:53 +00:00
2013-07-03 17:59:07 +00:00
2013-03-21 20:28:52 +00:00
2013-04-11 12:32:23 +00:00
2013-04-05 23:29:01 +00:00
2012-12-20 17:47:27 +00:00
2013-02-21 17:12:27 +00:00
2013-02-21 17:12:27 +00:00
2013-02-21 17:12:27 +00:00
2013-02-21 17:12:27 +00:00
2013-02-21 17:12:27 +00:00
2013-02-21 17:12:27 +00:00
2013-02-21 17:12:27 +00:00
2013-02-21 17:12:27 +00:00
2013-04-01 15:58:15 +00:00
2012-08-28 02:10:15 +00:00
2011-05-02 15:58:16 +00:00
2013-01-28 18:36:58 +00:00
2012-08-28 02:10:33 +00:00
2010-11-14 22:22:14 +00:00
2010-11-14 22:22:14 +00:00
2013-04-27 00:43:16 +00:00
2013-02-21 00:38:25 +00:00
2010-11-14 22:22:14 +00:00
2013-02-20 20:41:42 +00:00
2013-03-12 15:18:14 +00:00
2013-03-09 18:25:40 +00:00
2013-02-20 22:43:03 +00:00
2012-12-19 15:49:14 +00:00