https://sourceware.org/bugzilla/show_bug.cgi?id=34423
--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jan Beulich from comment #3)
> (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?
I am working on it.
> > > 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).
With
.long bar0 - .L4
.type bar0, @function
assembler knows bar0 is a function symbol.
--
You are receiving this mail because:
You are on the CC list for the bug.
