[PATCH] D15769: [ELF] - implemented R_386_TLS_IE_32 relocation.

George Rimar via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 24 06:18:43 PST 2015


grimar added a comment.

So problem I have in this patch is next. Assume we have the code below:
movl %gs:0,%eax
addl tls0 at gottpoff(%ebx),%eax

movl %gs:0,%eax
addl tls0 at gotntpoff(%ebx),%eax

First sequence generates R_386_TLS_IE_32, second generates R_386_TLS_IE. And the problem is
that such part of code looks to require 2 got entries. First one is entry for positive TLS offset,
second is GOT entry for positive TLS offset.
gold implementation contains enum allowing it to generate different GOT entries:

  enum Got_type
   {
     GOT_TYPE_STANDARD = 0,      // GOT entry for a regular symbol
     GOT_TYPE_TLS_NOFFSET = 1,   // GOT entry for negative TLS offset
     GOT_TYPE_TLS_OFFSET = 2,    // GOT entry for positive TLS offset
     GOT_TYPE_TLS_PAIR = 3,      // GOT entry for TLS module/offset pair
     GOT_TYPE_TLS_DESC = 4       // GOT entry for TLS_DESC pair
   };

We don`t have types of GOT entries. All we have now is uint32_t GotPltIndex; in SymbolBody.
Currently gold`s GOT_TYPE_TLS_OFFSET is only used for i386 R_386_TLS_IE_32 relocation so it is corner case.
I dont know how much is possible for one symbol to reproduce the case like above and require 2 entries.
So far I would suggest to check somehow that corner case and produce an "unsupported" error for now.
We could rewrite code in next way:
bool Regular = Target->requiresRegularGot(Type);

  ...
  unsigned IsRegularGot : 1;
  bool SymbolBody::isInGot(bool Regular) const {
    if (GotIndex == -1U)
      return false;
    if (IsRegularGot != Regular)
      error("...");
    return true;
  }
  ...
  template <class ELFT> void GotSection<ELFT>::addEntry(SymbolBody *Sym, bool Regular) {
    Sym->GotIndex = Target->getGotHeaderEntriesNum() + Entries.size();
    Sym->IsRegularGot = Regular;
    Entries.push_back(Sym);
  }

Another option would be to implement GOT entries types I think.


http://reviews.llvm.org/D15769





More information about the llvm-commits mailing list