[lldb-dev] [Reproducers] SBReproducer RFC

[Pavel Labath via lldb-dev]

On 09/01/2019 17:15, Jonas Devlieghere wrote:
> 
> 
> On Wed, Jan 9, 2019 at 5:05 AM Pavel Labath <pavel at labath.sk 
> <mailto:pavel at 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. :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
>     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).