Adding integer field to all C++ classes in LLVM


I want to add an integer field to all C++ classes in LLVM. Where do I look at in the LLVM source to make the necessary changes? As of now, what I understand is that I need to make changes in Type.cpp (llvm/lib/IR/Type.cpp) where I insert an integer field in the ArrayRef passed to StructType::setBody?



I take it you mean that you want to add a field to all classes COMPILED by LLVM, and not all classes that LLVM consists of?

Still, not sure if that is a good idea - I’m fairly sure the compiler (e.g. Clang) will make up its own classes that need to be of a certain size and have certain content to match external functionst that are not compiled at this time (e.g. data structures used to call OS system calls, C and C++ runtime functions, etc) [certainly my Pascal compiler produces internal structures in this way, for example for FILE, STRING and SET], and adding extra fields here would be pretty much guaranteed to cause things to go wrong. So a better idea is probably to understand what data structures are part of your actual source-code [not counting system header files such as , <stdio.h> or ], and add fields ONLY to those structures that “you own”, not the ones that clang produced internally. This would of course mean you have to do this either at the source level or in the AST of the compiler, not at LLVM level - but I’m fairly sure that doing this at LLVM level is a bad idea.

Also, unless I’m terribly misinformed, adding something to an ArrayRef is not going to work. ArrayRef, StringRef and such are “references to the original data in the calling code”, which means you have no right to modify it.

I’m pretty sure you are asking what is called an XY question, you want to do X, you think Y is the method of achieving that, and therefore ask how to do Y. I’m pretty sure asking how to achieve whatever X is in your case will provide you with better ideas of how to achieve what you want to do - as knowing what the actual goal is will help a lot in providing a

HI Mats,

Thanks for getting back to me.

Again, what are you trying to do, at a “big picture” level? What would be the purpose of object layout randomisation?

And for sure, you have to be VERY sure that this doesn’t break compatibility with other code compiled separately from this TU.

In other words, don’t break stdio.h’s FILE structures, some kind of OS data structures (or network protocols, file-system structures, xml-parser, Open{CL,GL,GLES,VX,CV,VG} packages, binary data stored in files, etc, etc). You can’t just modify struct/class content without understanding how it affects the rest of the system - so blindly adding something inside LLVM is highly unlikely to work. You need some way to understand WHAT data structures are “yours” and which ones are system/binary compatibility-dependent and can’t be changed without also changing things elsewhere.

Also consider if there is a user-defined struct T that is declared in a header file T.h and included in A.cpp that goes into LibA, and then included by B.cpp that makes LibB, and then main.cpp also uses T.h and links with LibA and LibB - the resulting struct T needs to be identical in layout in all three places, or bad things will happen.

If I was doing this, I would probably try to either modify the files in the project through some suitable script and/or using libclang/libtooling to parse the relevant code and output modified source, avoiding modification of system-files and out-of-project modules.

Clang is the code responsible for layout decisions, so LLVM is too late for this. Clang lowers sizeof, for example. If you want to change layout, see record layout builder in clang.