Re: Correct the type of _PROCEDURE_LINKAGE_TABLE_

[Ian Lance Taylor <ian at wasabisystems dot com>]

Daniel Jacobowitz <drow@false.org> writes:

> Three targets right now define elf_backend_want_plt_sym: sparc32,
> sparc64, and alpha.  None of them define elf_backend_plt_not_loaded, so
> you're right, this would change behavior on Solaris.  And I see that
> the native Solaris linker as of 2.8 still marks it as STT_OBJECT.

My general inclination in the early days was to copy the Solaris
linker.  That doesn't mean that we have to stick with that, of course.

> This is unfortunate for the same reason I originally proposed my patch. 
> If you take a stripped object, and run objdump -j .plt -d on it, you'll
> get code because of the section flags (objdump doesn't look at the
> dynamic symbol table, at least not the version my Solaris host has
> installed).  If you take an unstripped object and run the same command,
> you'll get data instead of disassembly.

Well, objdump -j .plt -D should always work.  In general -d will
produce results which differ between a stripped object and an
unstripped object.

> 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.

> > 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.

> 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.

Ian