https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82575
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> --- On October 19, 2017 2:33:17 PM GMT+02:00, amodra at gmail dot com <gcc-bugzi...@gcc.gnu.org> wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82575 > >--- Comment #5 from Alan Modra <amodra at gmail dot com> --- >> --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- >> Hmm, but those symbols will prevail, enlarging the final symbol >table? >> Or are weak + hidden symbols removed even for shared libaries? > >Well, they are still undefined. Being hidden they won't become >dynamic unless your linker is broken. OK. I suppose they are properly prevailed by any global symbol of the same name as well? Like a weak definition with default visibility? Or is there the chance of linker diagnostics about 'mismatches'? The patch looks OK otherwise, so if you post it I'll approve it. >> IIRC the Solaris linker didn't like to interpret "unused" (aka >unreferenced) > >From pr81968 it seems the symbol related complaint was just that the >linker warned on seeing a global symbol without name, which is kind of >reasonable given that a global symbol's linkage is via name. OK. >> UNDEF globals as irrelevant, complaining about missing symbols later. > GNU >> ld simply discards those in the partial link we perform over all >debug >> objects. > >Yes, it's possible that other linkers might not remove the undefined >symbols from .symtab, which would leave nm and other binutils broken. >If that happens, I suppose we could edit .strtab to change the name of >__gnu_lto_slim, or bump st_name by one. > >Changing global syms to local doesn't work since the locals must be >first in .symtab. Yeah, figured that out the hard way... Using STT_FILE would work with GNU ld, but it's >anybody's guess how global STT_FILE symbols are handled in other >linkers. OK. I might need to implement true section removal in the end (another Solaris linker diagnostic). So implementing true symbol removal is another possibility...
