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

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 15 16:16:56 PST 2018


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

> Rui Ueyama <ruiu at google.com> writes:
> >> 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.
>
> Sorry, meant in addition to the special case we already have. So
> something like this:
>
>
> if (Expr == R_NONE)
>   continue;
>
> // 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;
>
> // SBCL case..
> if (Expr == R_PC) {
>   ...
>   continue;
> }
>
> if (Expr != R_ABS) {
>    error
> }
>


Ah, that makes sense. I didn't notice that I accidentally changed the
behavior of the code for i386 GOTPC case.


> >> 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?)
>
> Thanks!
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180215/996730e0/attachment.html>


More information about the llvm-commits mailing list