Move some macros used in .asm files into header files.

[egrimley-arm]

The macros are defined in asm_offsets.h and the values are checked at compile time by asm_offsets.cpp.

A few other changes were needed to make this work:

• Some declarations are moved from mangle.c into a new file mangle.h.

• A declaration is moved from module_elf.c to module_private.h.

• A preprocessor check in opnd_api.h dating back to 2010 is removed.

• A small change in stats.h for compatibility with C++11.

[egrimley-arm]

One could use a helper program on the host to automatically generate the header files that define the offsets, but that would be much more complex to implement and an ongoing maintenance burden in the build system. Since these offsets are very rarely changed, and any change of them will typically involve simultaneous intricate changes to assembly and code that generates assembly I don't think it makes sense to generate the header files automatically. Better just to check the values with something like this approach.

One could use the preprocessor to make the source slightly simpler in a way, but it would then be much more complex in another way, and the error message when an offset is incorrect would be less readable, I think. Currently the error message looks like this:

.../dynamorio/core/arch/aarch64/offsets.c:9:9: error: size of array ‘x1’ is negative
    9 |     int x1[dcontext_t_OFFSET_dstack == offsetof(dcontext_t, dstack) ? 1 : -1];

I think that makes perfect sense to a programmer, and, if not, there's the comment preceding it in the source.

Another option would be to generate an error message at run time. You would then have total control over what the message looks like, but an error at build time seems better.

And using static_assert is certainly worth considering. I'm a bit confused about which versions of static_assert (or _Static_assert or whatever) are available with which versions of which compilers, and which header files need to be included to make them work, so perhaps for DynamoRIO it's better to use something totally portable like this array length trick.

[egrimley-arm]

Does this (https://github.com/DynamoRIO/dynamorio/actions/runs/12928500203/job/36055907604?pr=7202) make any sense to anyone?

aarch64-on-x86: **** 6 build errors ****
	/.../dynamorio/core/unix/../ir/opnd_api.h:47:6: error: #error REG_ enum conflict between DR and ucontext.h! Use DR_REG_ constants instead.
	make[2]: *** [core/CMakeFiles/dynamorio.dir/build.make:1021: core/CMakeFiles/dynamorio.dir/arch/aarch64/asm_offsets.cpp.o] Error 1

I don't understand how it's getting from #include "../globals.h" to including opnd_api.h, and there are other files which start by including globals.h. The error doesn't happen with my toolchain so it's hard for me to investigate.

[derekbruening]

Some of this looks like it should be generated using the "foox.h" pattern used in many other parts of DR (optionsx.h, statsx.h, kstatsx.h, etc.):

We'd have:

asm_offsetsx.h

OFFSET(spill_state_t, r1, 8)

arm_offsets.cpp

#define OFFSET(struct, field, value) CHECK(value == offsetof(struct, field));
#include "asm_offsetsx.h"

But I'm not sure it's possible to get arm_offsets.h to generate a literal without running some other script first (we'd try to use cmake to avoid pulling in more deps) -- so then the only win would be putting all the stuff you need to edit in the same place, which might still be worth it:

asm_offsetsx.h

OFFSET(spill_state_t, r1, 8)
#define spill_state_t_OFFSET_r1 8

arm_offsets.cpp

#define OFFSET(struct, field, value) CHECK(value == offsetof(struct, field));
#include "asm_offsetsx.h"

Now the only file a human edits is asm_offsetsx.h. Hmm. Worth it?

At least add a XXX comment about auto-generating via asm_offsetsx.h plus a script or a full script.

[egrimley-arm]

That sounds like a good idea. I'll try it.

[derekbruening]

This is a useful check: I don't think it should just be thrown away. If you hit it, that means there is a real enum conflict, doesn't it?

[egrimley-arm]

I don't know. It happened on the CI but I couldn't reproduce it locally. If I'm lucky the problem will go away when I stop using C++.