__start/__stop symbols not always defined
Alan Modra
amodra@gmail.com
Tue Jan 23 02:34:00 GMT 2018
More information about the Binutils mailing list
Tue Jan 23 02:34:00 GMT 2018
- Previous message (by thread): __start/__stop symbols not always defined
- Next message (by thread): New Bulgarian PO file for 'binutils' (version 2.30.0)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): __start/__stop symbols not always defined
- Next message (by thread): New Bulgarian PO file for 'binutils' (version 2.30.0)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list