macOS build failure due to conflicting defines in gdbremote/signals.hh

[gem5]

macOS build failure due to conflicting defines in gdbremote/signals.hh

[powerjg]

I'm a bit surprised this hasn't been caught as we often test on MacOS. Could you send your exact host setup (version of MacOS, etc.) and the exact build command you're using?

The solution is probably guarding these with #ifdef macos or something like that (I forget the exact syntax).

[austinharris]

macOS Ventura 13.4.1. I am building with scons build/ALL/gem5.opt with clang 11.1.0. The error arises from libSystem 11.0.0:

libSystem-11.0.0/include/mach/exception_types.h:87:33: note: expanded from macro 'EXC_BREAKPOINT' #define EXC_BREAKPOINT 6 /* Trace, breakpoint, etc. */

I don't think guarding these with ifdef is the solution as the values don't match. Let me know if there is any other info on dependencies needed.

[powerjg]

@BobbyRBruce, can you reproduce?

[BobbyRBruce]

I can't reproduce this on my Mac but I'm on Apple Silicon (ARM). @austinharris is your Mac Intel/X86? I can believe there are errors there as we don't test on those.

[chenbobby]

Hi, I am facing the same build error as @austinharris on macOS Apple Silicon (ARM). I have included notes on my error and details about my build environment below.

Explanation of the problem

It seems that there are name conflicts between mach/exception_types.h and gdbremote/signals.hh for the following names:

EXC_BAD_ACCESS
EXC_BAD_INSTRUCTION
EXC_ARITHMETIC
EXC_EMULATION
EXC_SOFTWARE
EXC_BREAKPOINT

mach/exception_types.h uses these names in #define macros and sets them to integer constants (for example, #define EXC_BAD_ACCESS 1), but gdbremote/signals.hh uses these names as variants in the enum class gem5::GDBSignal (for example, EXC_BAD_ACCESS = 145). Due to the name conflict, gdbremote/signals.hh fails to build with the error expected identifier, because the macro expansion results in the code 1 = 145, which is an invalid assignment.

Caveats

@austinharris's build is using mach/exception_types.h from libSystem, while my build is using mach/exception_types.h from XCode (I have provided my error logs below). I'm pretty sure the contents of these two files are the same, but not certain. If @BobbyRBruce is not facing the same errors on his Apple Silicon (ARM) machine, it may be because mach/exception_types.h is somehow not being used in the build...?

Possible solutions

1. Use an #ifdef guard so that we do not define gem5::GDBSignal::EXC_* for macOS. However, as @austinharris mentioned above, mach/exception_types.h and gdbremote/signals.hh uses different values for these names. Moreover, gdbremote/signals.hh is using these names as variants within an enum class, not as a #define macro.
2. Change the names of the gem5::GDBSignal::EXC_* in gdbremote/signals.hh and across the gem5 codebase?
3. Somehow avoid compiling mach/exception_types.h so that there are no macro naming conflicts?

Please let me know your thoughts or if I am missing anything. I'm happy to help open a PR to get this fixed and tested.

Build Environment

CPU: Apple M1 Pro (2021)
OS: macos 13.3.1 (Ventura)
Compiler toolchain: gcc (Homebrew GCC 13.1.0) 13.1.0
Scons version: v4.5.2.120fd4f633e9ef3cafbc0fec35306d7555ffd1db
gem5 version: commit f29bfc

Here's the build command that I ran:

$ python3 `which scons` build/X86/gem5.opt -j9

And here's the error log lines:

In file included from src/cpu/o3/probe/elastic_trace.cc:43:
In file included from src/cpu/o3/dyn_inst.hh:53:
In file included from src/cpu/checker/cpu.hh:51:
In file included from src/cpu/base.hh:60:
In file included from src/sim/system.hh:65:
In file included from src/sim/workload.hh:37:
ext/gdbremote/signals.hh:171:5: error: expected identifier
    EXC_BAD_ACCESS = 145, //could not access memory
    ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/mach/exception_types.h:68:33: note: expanded from macro 'EXC_BAD_ACCESS'
#define EXC_BAD_ACCESS          1       /* Could not access memory */
                                ^
In file included from src/cpu/o3/probe/elastic_trace.cc:43:
In file included from src/cpu/o3/dyn_inst.hh:53:
In file included from src/cpu/checker/cpu.hh:51:
In file included from src/cpu/base.hh:60:
In file included from src/sim/system.hh:65:
In file included from src/sim/workload.hh:37:
ext/gdbremote/signals.hh:172:5: error: expected identifier
    EXC_BAD_INSTRUCTION = 146, //illegal instruction/operand
    ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/mach/exception_types.h:72:33: note: expanded from macro 'EXC_BAD_INSTRUCTION'
#define EXC_BAD_INSTRUCTION     2       /* Instruction failed */
                                ^
In file included from src/cpu/o3/probe/elastic_trace.cc:43:
In file included from src/cpu/o3/dyn_inst.hh:53:
In file included from src/cpu/checker/cpu.hh:51:
In file included from src/cpu/base.hh:60:
In file included from src/sim/system.hh:65:
In file included from src/sim/workload.hh:37:
ext/gdbremote/signals.hh:173:5: error: expected identifier
    EXC_ARITHMETIC = 147, //arithmetic exception
    ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/mach/exception_types.h:75:33: note: expanded from macro 'EXC_ARITHMETIC'
#define EXC_ARITHMETIC          3       /* Arithmetic exception */
                                ^
In file included from src/cpu/o3/probe/elastic_trace.cc:43:
In file included from src/cpu/o3/dyn_inst.hh:53:
In file included from src/cpu/checker/cpu.hh:51:
In file included from src/cpu/base.hh:60:
In file included from src/sim/system.hh:65:
In file included from src/sim/workload.hh:37:
ext/gdbremote/signals.hh:174:5: error: expected identifier
    EXC_EMULATION = 148, //emulation instruction
    ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/mach/exception_types.h:78:33: note: expanded from macro 'EXC_EMULATION'
#define EXC_EMULATION           4       /* Emulation instruction */
                                ^
In file included from src/cpu/o3/probe/elastic_trace.cc:43:
In file included from src/cpu/o3/dyn_inst.hh:53:
In file included from src/cpu/checker/cpu.hh:51:
In file included from src/cpu/base.hh:60:
In file included from src/sim/system.hh:65:
In file included from src/sim/workload.hh:37:
ext/gdbremote/signals.hh:175:5: error: expected identifier
    EXC_SOFTWARE = 149, //software generated exception
    ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/mach/exception_types.h:82:33: note: expanded from macro 'EXC_SOFTWARE'
#define EXC_SOFTWARE            5       /* Software generated exception */
                                ^
In file included from src/cpu/o3/probe/elastic_trace.cc:43:
In file included from src/cpu/o3/dyn_inst.hh:53:
In file included from src/cpu/checker/cpu.hh:51:
In file included from src/cpu/base.hh:60:
In file included from src/sim/system.hh:65:
In file included from src/sim/workload.hh:37:
ext/gdbremote/signals.hh:176:5: error: expected identifier
    EXC_BREAKPOINT = 150, //breakpoint
    ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/mach/exception_types.h:87:33: note: expanded from macro 'EXC_BREAKPOINT'
#define EXC_BREAKPOINT          6       /* Trace, breakpoint, etc. */

[BobbyRBruce]

Yip! Can reproduce here! My issue was I was compiling with clang. Annoying Mac overrides 'gcc' and 'g++' with clang, so I needed to explicitly compile gem5 with CXX=g++-13 scons build/X86/gem5.opt -j12 after brew install gcc for the error to work).

I'll work on fixing this.

(Short term solution for those needing to compile quick: Install and use clang. I think CXX=clang++ scons build/X86/gem5.opt -j12 will work.

Nevermind, i misspoke. Still working on recreating this. Think I may be unable to due to me not installing xcode. Will try that.

[chenbobby]

It's okay! Thanks for taking a look at this. Hopefully we can resolve this soon.

Just want to confirm that using clang++ didn't fix the problem for me. 🥲

For the record, my clang++ --version will output the following:

Apple clang version 14.0.3 (clang-1403.0.22.14.1)
Target: arm64-apple-darwin22.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[BobbyRBruce]

Hey @chenbobby (the other Bobby): Can you see if #209 fixes your issue?

I cannot recreate this on my end but I suspect your idea of renaming the EXC_ would fix things. Can you see if incorporating this change fixes things for you?

I'm honestly not entirely sure how important these values in "ext/gdbremote/signals.hh" are. I hope this doesn't break anything.

[powerjg]

Does anyone know why mach/exception_types.h is included in gem5's build? I can't imagine that gem5's build needs a MacOS-specific file.

[chenbobby]

Hi @BobbyRBruce, #209 does indeed fix this issue for me. 🙌 🙏

I'm now dealing with some build issues with protobuf 😅 But that seems unrelated to this issue.

[BobbyRBruce]

@chenbobby : Great!

I've never tried using protobuf on a Mac before. If the issue persists then, if you have the time, please log it as an issue. If there are bugs or pitfalls here then I doubt you're the only one to encounter them.

FYI: protobuf isn't required for gem5 compilation but you do need it for trace generation and playback functionality. If you don't need that then it's safe to remove.

[austinharris]

Does anyone know why mach/exception_types.h is included in gem5's build? I can't imagine that gem5's build needs a MacOS-specific file.

I believe it is just included in every user-level program in order to handle exceptions such as system calls.

[BobbyRBruce]

This issue is fixed by the merging of #209 (at least, for now, on the develop branch).