Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

egrimley-arm
Copy link
Contributor

The macros are defined in offsets.h and the values are checked at compile time by offsets.c.

The macros are defined in offsets.h and the values are checked
at compile time by offsets.c.

Change-Id: I0a22ae5c0046769dc3fb763db8904d52530e48af
@egrimley-arm
Copy link
Contributor Author

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.

#include "../globals.h"
#include "offsets.h"

/* This is an alternative to using static_assert that will work with
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we could use static_assert as for C++ we require C++11 (and already use it in our C++ code), for Visual Studio we require VS2019, and while our UNIX has gnu99 the GNU extensions provide _Static_assert. Could do sthg like #if defined(__cplusplus) && !defined(_Static_assert) #define _Static_assert static_assert #endif and then use _Static_assert everywhere: or define a new STATIC_ASSERT that takes in a message.

@@ -336,6 +336,10 @@ if (X86 AND X64)
set(ARCH_SRCS ${ARCH_SRCS} arch/${ARCH_NAME}/x86_to_x64.c)
endif (X86 AND X64)

if (AARCHXX)
set(ARCH_SRCS ${ARCH_SRCS} arch/${ARCH_NAME}/offsets.c)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would agument the name: either asm_offsets.{c,h} or struct_offsets.{c,h}.

#ifndef _offsets_h
#define _offsets_h

/* The following macros are used in .asm files to refer to C structs.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The general approach seems good: take advantage of our use of the preprocessor in our asm files to share a header with a checking file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants