On 09/01/2019 17:15, Jonas Devlieghere wrote:
On Wed, Jan 9, 2019 at 5:05 AM Pavel Labath <pa...@labath.sk
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
You gave up way too easily. :P
I 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
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