https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91478
--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 23 Aug 2019, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91478 > > --- Comment #10 from Martin Liška <marxin at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #9) > > Yeah, we went though this back in time when I struggled to find a solution > > working in all environments we support (HP ld, Solaris ld, AIX ld). > > Hm, does it mean I'll have to revert all the removal of gnu_lto_v1? Well, at least I doubt we can add a weak def of "". As I said repeatedly the other option is to really remove symbols but that entails rewriting all relocation sections (ick). Previously we've had libgcc "provide" the __gnu_lto_v1 symbol (that was a hack, but it worked...). I guess we might want to at least _try_ doing the right thing and remove the symbols for real... I guess rematerializing gnu_lto_v1 just for the sake of removed symbols would be odd. I wonder what happens when we instead of aliasing the removed to UNDEF gnu_lto_v1 (or "" as now) use a random symbol that prevails... (we should have at least one for the debuginfo entry). Then we'd have 19: 0000000000000000 0 NOTYPE WEAK HIDDEN 4 t.c.61d57031 20: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND t.c.61d57031 for example. Of course we then need to figure which linkers are happy with that and which not... And we need to do two passes over the symtab as we need to find a prevailing symbol to use.
