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

Rafael Avila de Espindola via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 15 15:40:32 PST 2018


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?

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.

Cheers,
Rafael


More information about the llvm-commits mailing list