Re: Correct the type of _PROCEDURE_LINKAGE_TABLE_

[Daniel Jacobowitz <drow at false dot org>]

On Fri, May 28, 2004 at 09:54:57AM -0400, Ian Lance Taylor wrote:
> Daniel Jacobowitz <drow@false.org> writes:
> 
> > > > > > objdump will not dump the PLT as instructions if it starts
> > > > > > with an STT_OBJECT symbol.
> > > > > 
> > > > > Really?  Fix objdump then.  _PROCEDURE_LINKAGE_TABLE_ isn't a function,
> > > > > nor are many other symbols in code sections.
> > > > 
> > > > >From the gABI:
> > > > 
> > > > STT_OBJECT
> > > >                   The symbol is associated with a data object, such as a variable,
> > > >                   an array, and so on.
> > > > 
> > > > STT_FUNC
> > > >                   The symbol is associated with a function or other executable
> > > >                   code.
> > > > 
> > > > _PROCEDURE_LINKAGE_TABLE_ in this case is "other executable code", and not a "data
> > > > object", so I think it should be STT_FUNC.
> > > 
> > > Isn't a table an array of sorts?  Perhaps it won't hurt anything to
> > > change the type, but who knows?  If you can twist Ian's arm to approve
> > > it, then fine!  Otherwise, I'm inclined to be grumpy and reject the
> > > patch.
> > 
> > A mighty messed up array, if you ask me.  OK.  Ian, any comment?
> 
> Ummm.
> 
> I think I originally made _PROCEDURE_LINKAGE_TABLE_ an STT_OBJECT
> symbol because that is what the Solaris linker did.  Your patch would
> make it into an STT_FUNC symbol on most targets, including Solaris.

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.

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.

> I think it would clearly be incorrect to make
> _PROCEDURE_LINKAGE_TABLE_ an STT_FUNC symbol in a .o file, since that
> could cause various sorts of bad linkage.  But of course
> _PROCEDURE_LINKAGE_TABLE_ doesn't appear in .o files.
> 
> I suppose that when I think of _PROCEDURE_LINKAGE_TABLE_, I think of
> it as naming a data object: the procedure linkage table, in fact.
> It's true that there is often code at that address.  But it's not
> really a function in any sense.

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.

>  Most of the entries in the PLT come
> with their own STT_FUNC symbols.  So at least in most cases we are
> only talking about the bit of code which comes at the start of the
> PLT.

Hmm, they get their own STT_FUNC symbols marked UND, and objdump
ignores them.  So it just does whatever the beginning symbol says for
the whole section.  That, arguably, may be a bug.  I don't think it's
the whole bug though.

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

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.

-- 
Daniel Jacobowitz