[PATCH] D43351: Relax relocation type checking in a non-ALLOC section.

[Rui Ueyama via llvm-commits]

On Thu, Feb 15, 2018 at 3:40 PM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

> Rui Ueyama via Phabricator <reviews at reviews.llvm.org> writes:
> > Index: lld/ELF/InputSection.cpp
> > ===================================================================
> > --- lld/ELF/InputSection.cpp
> > +++ lld/ELF/InputSection.cpp
> > @@ -651,17 +651,25 @@
> >      RelExpr Expr = Target->getRelExpr(Type, Sym, BufLoc);
> >      if (Expr == R_NONE)
> >        continue;
> > -    if (Expr != R_ABS) {
> > -      // GCC 8.0 or earlier have a bug that it emits R_386_GOTPC
> relocations
> > -      // against _GLOBAL_OFFSET_TABLE for .debug_info. The bug seems to
> have
> > -      // been fixed in 2017: https://gcc.gnu.org/bugzilla/
> show_bug.cgi?id=82630,
> > -      // but we need to keep this bug-compatible code for a while.
> > -      if (Config->EMachine == EM_386 && Type == R_386_GOTPC)
> > -        continue;
> >
> > -      error(getLocation<ELFT>(Offset) + ": has non-ABS relocation " +
> > -            toString(Type) + " against symbol '" + toString(Sym) + "'");
> > -      return;
> > +    if (Expr != R_ABS) {
> > +      // If the control reaches here, we found a PC-relative relocation
> in a
> > +      // non-ALLOC section. Since non-ALLOC section is not loaded into
> memory
> > +      // at runtime, the notion of PC-relative in such section doesn't
> make
> > +      // sense. So, this is a usage error. However, GNU linkers
> historically
> > +      // accept such relocations without any error and relocate them as
> if
> > +      // they were at address 0. For bug-compatibilty, we accepts them
> with
> > +      // warnings.
> > +      //
> > +      // GCC 8.0 or earlier emit such relocations due to a bug [1].
> Steel Bank
> > +      // Common Lisp as of 2018 emits them too.
> > +      //
> > +      // [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82630
>
> There are a lot of relocations that are not R_ABS or R_PC. Could we
> limit this to R_PC and still error on other expressions?
>

I just tried and unfortunately limiting it to R_PC doesn't work. In
particular, GCC 8.0 or earlier create R_386_GOTPC relocations in a
non-allocated section. We have a test for it, and if we limit it to R_PC,
that test starts failing.


> Could you report a bug on SBCL? It is OK to have a workaround, but it
> is nice to at least let them know of the bug.
>

I already filed a bug. I mailed to sbcl-bugs@, and it should be filed to
their bug management system soon. (I guess it's manual?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180215/0abd5336/attachment.html>