On Tue, Mar 10, 2020 at 11:05 AM Martin Liška <mli...@suse.cz> wrote: > > On 3/9/20 9:19 PM, Jan Hubicka wrote: > >> On Mon, Mar 9, 2020 at 9:56 AM Martin Liška <mli...@suse.cz> wrote: > >>> > >>> On 3/9/20 4:36 PM, H.J. Lu wrote: > >>>> We nee to support different variables, like TLS, data and bss variables. > >>> > >>> Why do we need TLS? Right now, it's not supported by nm. Or am I wrong? > >> > >> Since you are introducing symbol types, why not support TLS? > >> > >>> About BSS and DATA I agree that it would be handy. I can theoretically > >>> covered with code in get_variable_section/bss_initializer_p. But it's > >>> quite logic and I'm not sure we should simulate it. > > > > I think it should not be that hard to factor out the logic from > > get_variable_section to return enum of what we want to do and then > > have get_variale_section as a wrapper parsing this enum to actual > > section. > > So it was easier that I expected and I'm sending updated version > of the patch. > > >>> > >>> @Honza/Richi: Do you have any opinion about that? > > > > I guess we indeed want to get as close to non-LTO nm behaviour as > > possible. So we want to support them and perhaps think of .symtab > > section file format that can be made backward compatible (such as having > > attribute string for symbols where we can add new info in future in a > > way that old plugins will still get info they want). > > I like the idea. But it's probably next stage1 material. Or can you prepare > a patch?
I think what's important is that the LTO plugin needs to understand the old and the new version since there's only one for auto-loading. The other missing feature of the linker plugin API is file claiming which should be a on a section basis instead - but that's a different part of the API and not related to symbol tables. Enhancing that part of the API would allow to elide the LTO debug copying ... > > > > Of course IPA optimizations may migrate symbols around (say from data to > > bss)/take them away/rename them, but with that we need to live. I would > > expect most tools inspecting nm are interested in what will enter > > linking not what will be in final output. > > Yes, there are mostly used during configure script run where they commonly > do not take final linked executables/shared libs. > > > > > Since we discuss plugin extensions (and I do not want this to complicate > > finishing Martin's patch). > > Please suggest that in another patch. > > The current situation with binutils is bad because we can't build distribution > with -fno-common and LTO. > > Martin > > > Are we aware of other plugin limitations? > > One thing that I consider unsafe is the way we produce local names when > > we need to promote symbol to hidden due to partitining. We add > > .lto_priv, but that is not safe if we link with .o file that was > > incrementally lto-optimized to target object file (this is reason why I > > did not enabled WHOPR path for it). > > > > We may also want to inform lld and llvm's gold plugin maintainers about > > intended changes. > > Honza > >>> > >>> Thanks, > >>> Martin > >> > >> > >> > >> -- > >> H.J. >