Question

I was debugging some C++ code in GDB and I found out that some calls were making use of a so-called “synthetic pointer”. Googling around did not produce any meaningful result. Searching here on SO, most questions with “synthetic” in their title refer to some Java feature (even if they suggest me that “synthetic”, in this context, could mean “something generated artificially by the compiler”).

E.g., look at this backtrace, took from one operation, performed in the constructor of MyClass, over one class member called m (this code has been compiled with -O2):

#0  MyClass (arg=..., this=<synthetic pointer>) at somefile.h:144
144     m->lock();
gdb$ print this
$1 = (MyClass * const) <synthetic pointer>
gdb$ print *this
$2 = <optimized out>

The stack trace above clearly states that this is a pointer to an object that has been optimized out, but how is it possible that a method (i.e., its constructor) has been called on it? My wild guess is that, even if the enclosed object (m) is actively used in the code, some optimizations let the compiler decide that the enclosing object (this) is not really necessary. Since the method call m->lock(), that cannot be optimized out, must be emitted somewhere, the compiler creates a “fake” (synthetic?) object, located nowhere in memory, just to wrap m.

I do not have a strong compiler experience, so I do not know if this conclusion really makes sense. Could someone please shed some light on this?

Thank you.

Answer 1

A compiler can determine whether this is actually dereferenced (i.e. using the specific CPU details, not the general C++ rules). If a method doesn’t actually dereference this, there’s no need to have a phyiscal representation available.

[edit]
In the comments, jww mentioned another case. A singleton has only one copy, so a smart compiler can treat its members as globals. That means the address of singleton->foo is just the constant &singleton + offset(foo). As a result of this optimization, the singleton methods don’t need to actually dereference this either to get access to the singleton members, so it again can be optimized out.