Ok, thanks, I figured there must be some options to support this sort of thing. In the past, I've wanted the ability to add extra flags to the compile step of certain object files (primarily adding include paths in those cases), and if we had something like that we could selectively change the symbol visibility for areas where we knew it would be safe (generated code seems like low hanging fruit). Maybe that's something to pursue? It would require a non-trivial refactor of the scons interface, but I think it could be done and essentially preserve compatibility.
Gabe On Thu, May 24, 2018 at 10:17 AM, Andreas Sandberg <[email protected] > wrote: > Hi Gabe, > > I think this would make sense. There is a linker/compiler optino, > -fvisibility=hidden, that changes the default behaviour. Once you have > that, you need to explicitly tell the compiler to make a symbol public > using an attribute. I have run into cases where the current policy > breaks some PyBind wrappers since PyBind symbols are hidden by default [1]. > > The main issue with this approach is that it potentially breaks the C++ > wrapper since we don't have a well-defined API. In practice, we probably > only need to export the factory functions and the methods we declare as > Python APIs. > > Cheers, > Andreas > > [1] > http://pybind11.readthedocs.io/en/stable/advanced/misc.html# > partitioning-code-over-multiple-extension-modules > > > On 22/05/2018 11:18, Gabe Black wrote: > >> Hi folks. I've been pretty busy and so haven't had a chance to look into >> this at all, but I was wondering if there was a good way to turn symbols >> which are only useful in a particular context (constructors for >> instruction >> objects maybe?) into local symbols which won't be considered by the linker >> as part of the global link, assuming some local partial link step >> happened. >> It seems like this would have the potential to speed up the final link a >> lot since I imagine there are *lots* of symbols that come from instruction >> objects that are never referred to outside of, say, the decode >> function/object, or minimally the ISA. >> >> Has anybody tried anything like that? Does that seem like something worth >> pursuing? Besides fancy linker tricks, it might be possible to hide those >> symbols using normal C++ mechanisms. I don't know exactly how that would >> be >> done, but there are a lot of gadgets built into C++ these days. >> >> Anyway, I thought I should toss that out into the ether before I forgot >> about it in case some adventurous soul wanted to look into it. >> >> Gabe >> _______________________________________________ >> gem5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/gem5-dev >> > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
