https://sourceware.org/bugzilla/show_bug.cgi?id=34423
--- Comment #3 from Jan Beulich <jbeulich at suse dot com> ---
(In reply to H.J. Lu from comment #2)
> (In reply to Jan Beulich from comment #1)
> > But, first of all, bar<N> would normally be defined in the same TU. Albeit
> > perhaps this makes no difference here.
>
> bar<N> can be external functions called via PLT.
Sure, but is there a way to have such a jump table created by the compiler?
> > Second, in a .long (or other data) directive, how would you pick between
> > PC32 and PLT32? Aiui it would need to be the compiler to request this, by
> > using @plt. Otherwise we have no way to disambiguate.
> >
> > Which then runs foul of gas not permitting:
> >
> > .long bar0@plt - .L4
>
> When bar0 is an external function, assembler accepts
> ".long bar0 - .L4".
Creating a PC32 reloc for it.
> But linker generates R_X86_64_PC32 run-time relocation:
Sure, as that's what the object file says.
> Can we generate R_X86_64_PLT32, instead of R_X86_64_PC32,
> against undefined function symbol?
Imo only if the source is saying so. And once it does, whether the symbol is a
function one won't matter anymore (apart from possibly controlling emission of
a warning). I.e. first thing is to make gas properly accept
.long bar0@plt - .L4
(without it accepting other, bogus constructs).
--
You are receiving this mail because:
You are on the CC list for the bug.
