Tag: tools

Posted on

Name mangling in C++ with Clang and GCC

I recently came across the question whether it is possible to use lists of mangled function names (generated with a Clang-based tool) in a GCC compiler plugin. I am aware that name mangling is compiler dependent and not standardized, yet I had hopes that this would be something I can achieve.

I started with a quick web search. That, however, did not lead to satisfying answers, as I was still unsure whether it could actually work. Most of the answers I found were about the status when GCC 5 came out. Now, I am working with GCC 8 and things may change.

So, I continued by implementing very basic test cases to start this off experimentally, i.e., to get an idea on whether more reading about all this is worth my time. Codes were as simple as the one shown below. The first name in the comment is the GCC mangled name (g++ 8.3) and the second name is the Clang mangled name (clang++ 9.0).

void foo() {} // _Z3foov == _Z3foov
void foo(int a){} // _Z3fooi == _Z3fooi
double foo(double d){return 0;} // _Z3food == _Z3food
void foo(int a, double d) {} // _Z3fooid == _Z3fooid
namespace test {
 void foo(int a) {} // _ZN4test3fooEi == _ZN4test3fooEi
 double foo(double d) {return 0;} //_ZN4test3fooEd == _ZN4test3fooEd
}

So, at least given this small set of samples, there do not seem to be differences. I did similar tiny-scale experiments for classes and templates. All of them were simple enough to not discover differences. Eventually, I applied both compilers to a basic C++ implementation of the game of life (sources) and filtered the object code to get a list of all the function names in the resulting binary. I compiled at optimization level 0 to let the compiler not do inlining or other optimizations. I’m sure listing all functions in an object can be done much easier (e.g., using nm), but this is what I did (accordingly for a version of the code compiled with g++):

objdump -d clang++90.GoL | grep ">:" | awk '{ print $2 }' | sed -e "s/://" | uniq | sort > clang++90_names

Inspecting both lists of generated function names, I found differences. In particular, in the mangled name of the constructor of the GameOfLife class.

class GameOfLife {
  public:
    GameOfLife(int numX, int numY) : dimX(numX), 
                                     dimY(numY), 
                                     gridA(dimXdimY,
                                     gridB(dimXdimY){}
    // other members are omitted
};

The constructor is mangled into _ZN10GameOfLifeC1Eii by GCC and into _ZN10GameOfLifeC2Eii by Clang. The difference is the C1 vs. the C2 in the name.

Now, I wondered: what is encoded by these C1 / C2 parts of the mangled name? I know that Clang mangles the names according to the Itanium IA64 ABI specification. A quick web search lead me here and so I searched for the respective section of the specification. I found that the specification lists the following in 5.1.4.3 Constructors and Destructors.

  <ctor-dtor-name> ::= C1	# complete object constructor
		   ::= C2	# base object constructor
		   ::= C3	# complete object allocating constructor
		   ::= D0	# deleting destructor
		   ::= D1	# complete object destructor
		   ::= D2	# base object destructor

So, GCC treats the constructor of the GameOfLife class as a complete object constructor, whereas Clang treats it as a base object constructor.

At that point I did not continue digging deeper on why that is the case, i.e., thoroughly reading the IA64 ABI specification definitions, as for me it is sufficient to know that the differences in name mangling occur at such fundamental features as constructors. However, maybe, if someone (or a future me) has the same question (again), I thought I share this in order to know where to start looking for more detail.

Finally, the overall result of this small research is that I will need to write an LLVM plugin to mimic the functionality of the respective GCC plugin I wanted to use in my toolchain. Nothing too bad, but I would have been happier if I could just use the already available GCC plugin.

Posted on

Overleaf for collaborative writing

We started to use Overleaf for collaborative writing of our research papers. After a few papers and other documents, I decided I share my experiences with it.

First, what did we do before we started using Overleaf?

Well, we used a git repository for the paper to synchronize the changes between different authors. Everybody used their favorite text editor and we agreed on some code style. My experience was that the most important thing is: write one sentence per line, because it makes merging just so much easier. Then we would send the pdf of the draft to whoever is doing the internal review. We get back a paper copy with handwritten remarks to be included and iterate the whole process. This isn’t bad, and I totally understand if people prefer to read on a printed out copy.

Now, how did Overleaf change this?

Overleaf is a little bit like multiplayer LaTeX. What we found to be more important: it sets up the pdf version of the paper immediately. This is particularly helpful for the internal review – at least in our group. With its comment mechanism, people can simply annotate the respective parts of the document. If they only found a typo, they can also immediately fix it in the document. This makes the review easier and faster accessible. I would, however, agree that the introduction of Overleaf is not the most important thing that ever happened.

That’s all great! What can’t it do?

I found it to be somewhat annoying that the editor is an always-on solution! You cannot, at least I did not see how, make the document / editor available offline to, say, work on a document while flying across the Atlantic [Yes, I am assuming you do not want to use the WiFi in the plane]. If you dig a little bit into it, you find that the Overleaf document is actually a git repository behind the scenes. Let’s just clone it, so we can work offline and then push the changes. Unfortunately, you can’t do this. The first part worked smoothly: cloning the project’s git. The second part, pushing changes to it, failed. At least I did not manage to add my credentials in a way that allowed me to push changes to the remote.

So what’s the conclusion?

My conclusion is: Overleaf provides a convenient way to collaborate with authors from other groups / institutions easily. It allows for nice and easy WYSIWYG reviewing and you can export the final document as a git to store it on your local git server, if you want to do so, e.g., for archiving purposes. Should you mostly find time to work on documents while you don’t have Internet access, Overleaf may not be the best solution.