> 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. > > > > @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). 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. Since we discuss plugin extensions (and I do not want this to complicate finishing Martin's patch). 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.
