On 09/01/2019 17:15, Jonas Devlieghere wrote:
On Wed, Jan 9, 2019 at 5:05 AM Pavel Labath <pa...@labath.sk <mailto:pa...@labath.sk>> wrote:On 08/01/2019 21:57, Jonas Devlieghere wrote: > Before I got around to coding this up I realized you can't take the > address of constructors in C++, so the function address won't work as an > identifier. > You gave up way too easily. :PI counted on you having something in mind, it sounded too obvious for you to have missed. ;-)I realized that constructors are going to be tricky, but I didn't want to dive into those details until I knew if you liked the general idea. The most important thing to realize here is that for the identifier thingy to work, you don't actually need to use the address of that method/constructor as the identifier. It is sufficient to have something that can be deterministically computed from the function. Then you can use the address of *that* as the identifier.I was thinking about that yesterday. I still feel like it would be better to have this mapping all done at compile time. I was considering some kind of constexpr hashing but that sounded overkill.
Well.. most of this is done through template meta-programming, which _is_ compile-time. And the fact that I have a use for the new construct/invoke functions I create this way means that even the space used by those isn't completely wasted (although I'm sure this could be made smaller with hard-coded IDs). The biggest impact of this I can think of is the increased number of dynamic relocations that need to be performed by the loader, as it introduces a bunch of function pointers floating around. But even that shouldn't too bad as we have plenty of other sources of dynamic relocs (currently about 4% of the size of liblldb and 10% of lldb-server).
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
