https://sourceware.org/bugzilla/show_bug.cgi?id=32196
Jan Beulich <jbeulich at suse dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jbeulich at suse dot com
Status|RESOLVED |REOPENED
Resolution|FIXED |---
--- Comment #5 from Jan Beulich <jbeulich at suse dot com> ---
(In reply to Fangrui Song from comment #4)
> With the latest change, call local@plt doesn't generate a relocation when
> the symbol is a local symbol in the same section. However, movq $local@PLT,
> %rax generates a relocation, which is redundant.
Whether it's "redundant" can only be known by inspecting subsequent code. In
fact, the programmer writing @PLT (or any other @...) ought to result in
exactly what is asked for. Zapping the PLT reloc (ro, again, any other one) may
be done as an optimization, but like for any other optimizations that shouldn't
be active by default.
The code change done also looks wrong to me, as does the related error raised
by x86_cons(): Both R_386_PLT32 and R_X86_64_PLT32 are clearly specified as
PC-relative. There cannot be non-PC-relative forms, and hence plain uses of
symbol@PLT are valid only in PC-relative context (CALL, JMP, Jcc, XBEGIN, and
%rip-relative addressing). Other uses need to be spelled out as PC-relative
(symbol@PLT - .) to be valid.
Note also that while the check in x86_cons() rejects e.g.
.slong plt32@plt - .
all of
mov $plt32@plt, %eax
mov $plt32@plt - ., %eax
(32-bit) and
mov $plt32@plt, %rax
mov $plt32@plt - ., %rax
(64-bit) are accepted, the respectively former yielding the code + relocation
that the respectively latter should yield ("plt32" being a local symbol).
--
You are receiving this mail because:
You are on the CC list for the bug.
