<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 15, 2018 at 3:40 PM, Rafael Avila de Espindola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Rui Ueyama via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> writes:<br>
> Index: lld/ELF/InputSection.cpp<br>
> ==============================<wbr>==============================<wbr>=======<br>
> --- lld/ELF/InputSection.cpp<br>
> +++ lld/ELF/InputSection.cpp<br>
> @@ -651,17 +651,25 @@<br>
>      RelExpr Expr = Target->getRelExpr(Type, Sym, BufLoc);<br>
>      if (Expr == R_NONE)<br>
>        continue;<br>
> -    if (Expr != R_ABS) {<br>
> -      // GCC 8.0 or earlier have a bug that it emits R_386_GOTPC relocations<br>
> -      // against _GLOBAL_OFFSET_TABLE for .debug_info. The bug seems to have<br>
> -      // been fixed in 2017: <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82630" rel="noreferrer" target="_blank">https://gcc.gnu.org/bugzilla/<wbr>show_bug.cgi?id=82630</a>,<br>
> -      // but we need to keep this bug-compatible code for a while.<br>
> -      if (Config->EMachine == EM_386 && Type == R_386_GOTPC)<br>
> -        continue;<br>
><br>
> -      error(getLocation<ELFT>(<wbr>Offset) + ": has non-ABS relocation " +<br>
> -            toString(Type) + " against symbol '" + toString(Sym) + "'");<br>
> -      return;<br>
> +    if (Expr != R_ABS) {<br>
> +      // If the control reaches here, we found a PC-relative relocation in a<br>
> +      // non-ALLOC section. Since non-ALLOC section is not loaded into memory<br>
> +      // at runtime, the notion of PC-relative in such section doesn't make<br>
> +      // sense. So, this is a usage error. However, GNU linkers historically<br>
> +      // accept such relocations without any error and relocate them as if<br>
> +      // they were at address 0. For bug-compatibilty, we accepts them with<br>
> +      // warnings.<br>
> +      //<br>
> +      // GCC 8.0 or earlier emit such relocations due to a bug [1]. Steel Bank<br>
> +      // Common Lisp as of 2018 emits them too.<br>
> +      //<br>
> +      // [1] <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82630" rel="noreferrer" target="_blank">https://gcc.gnu.org/bugzilla/<wbr>show_bug.cgi?id=82630</a><br>
<br>
</div></div>There are a lot of relocations that are not R_ABS or R_PC. Could we<br>
limit this to R_PC and still error on other expressions?<br></blockquote><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Could you report a bug on SBCL? It is OK to have a workaround, but it<br>
is nice to at least let them know of the bug.<br></blockquote><div><br></div><div>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?)</div></div></div></div>