This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]