This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Correct the type of _PROCEDURE_LINKAGE_TABLE_
On Fri, May 28, 2004 at 10:26:07AM -0400, Ian Lance Taylor wrote:
> > That's why I quoted the gABI. STT_FUNC does not mean function - it
> > means "function or other executable code". To me it seems natural that
> > the code in the PLT is code rather than data. Both you and Alan seem
> > to disagree with me, which is a pretty strong deterrant.
>
> My feeling is that the symbol _PROCEDURE_LINKAGE_TABLE_ is associated
> with the whole PLT, which on many targets includes both code and data.
Not on any of the affected targets, I think. There are some nops and
zeros that get replaced by other code by the dynamic linker, but no
strict data.
> > > My inclination is to agree with Alan, and to say that we should fix
> > > objdump. But I don't feel very strongly about it.
> >
> > If we fix objdump, I think we'll break whatever support there was for
> > ARM mapping symbols, which use the ELF symbol type (as well as the
> > magic names) to indicate whether something is code or data. That's
> > fixable since we could fall back on the magic names, but we'll also try
> > to disassemble other data objects that got placed in .text. Seems like
> > a shame.
>
> Yes, that would be breaking objdump, not fixing it. Fixing objdump
> would mean recognizing that _PROCEDURE_LINKAGE_TABLE_, or the .plt
> section, is a special case. That probably wouldn't be done in objdump
> itself, though. This is a hack, but not a horrible one: the PLT
> really is a special case.
We could do that.
> > For what it's worth, I have another proprietary toolchain that does use
> > STT_FUNC, which started me thinking about this. Neither that toolchain
> > nor Sun's appears to have any documentation rationalizing the choice.
>
> I think either choice is defensible. As I said, I don't feel too
> strongly about it.
You don't feel strongly, and Alan's opposed, so I'll drop the patch.
You may see it again wrapped in a different backend macro, someday :)
--
Daniel Jacobowitz