__start/__stop symbols not always defined

[Alan Modra]

On Mon, Jan 22, 2018 at 03:31:19PM +0100, Michael Matz wrote:
> Hi,
> 
> On Fri, 19 Jan 2018, Alan Modra wrote:
> 
> > Right, and that documentation goes all the way back to 2008-05-21.
> > 
> > I'm not discounting your comments about dlopen and dlsym, but I believe 
> > the current behaviour is reasonable and likely gives what most people 
> > want, particularly those who are concerned about symbol table size.
> 
> Okay, I can live with this; the pacemaker guys will have to invent 
> something then (or stay with what they invented already :) ).  (Though 
> symbol table size ... hmm, it's only for C-representable names, i.e. by 
> default none)

I know the symbol table size argument is weak.  ;-)

> > -u __start___verbose on the ld command line ought to work.
> 
> Yeah, I should have mentioned this.  I tried before writing the mail and 
> it doesn't work completely.  When you have a library providing those 
> symbols already:

Ah, yes, that would stop the symbols being provided.  We don't set
ref_regular on -u symbols.

> (or a mirroring change in the predicate of bfd_elf_define_start_stop 
> rejecting only-dynamic definitions as satisfying)

That makes some sense to me.  It does mean that __start and __stop
symbols don't behave exactly like PROVIDEd symbols, but perhaps that's
not unreasonable.  Should be safe.

-- 
Alan Modra
Australia Development Lab, IBM