Page MenuHomePhabricator

lldb - __arm64__ vs __aarch64__ insanity
ClosedPublic

Authored by pawelo on Jul 3 2014, 2:10 PM.

Details

Reviewers
tfiala
Summary

It's started with simple program:

#ifdef i386
#warning this is i386
#else
#warning this is NOT i386
#endif

#ifdef x86_64
#warning this is x86_64
#else
#warning this is NOT x86_64
#endif

#ifdef aarch64
#warning this is aarch64
#else
#warning this is NOT aarch64
#endif

#ifdef arm64
#warning this is arm64
#else
#warning this is NOT arm64
#endif

#ifdef arm
#warning this is arm
#else
#warning this is NOT arm
#endif

When cross-compiling on Linux for AArch64 using Linaro toolchain, the pre-processor produces following output:
$ aarch64-linux-gnu-gcc-4.8.2 -Wall -c aarch64.c
aarch64.c:4:2: warning: #warning this is NOT i386 [-Wcpp]
#warning this is NOT i386

^

aarch64.c:10:2: warning: #warning this is NOT x86_64 [-Wcpp]
#warning this is NOT x86_64

^

aarch64.c:14:2: warning: #warning this is aarch64 [-Wcpp]
#warning this is aarch64

^

aarch64.c:22:2: warning: #warning this is NOT arm64 [-Wcpp]
#warning this is NOT arm64

^

aarch64.c:28:2: warning: #warning this is NOT arm [-Wcpp]
#warning this is NOT arm

^

I expect that other cross-compilers define arm64 instead of aarch64 (or both), so there's my patch that causes checking for both. This is all-or-nothing approach, I did not try to investigate whether any of the parts of affected code are compiled on Linux or MacOSX - I altered all places where arm64 was used.
Before applying, it's worth to try if it still builds for ARM64 on MacOSX.

Diff Detail

Event Timeline

pawelo updated this revision to Diff 11066.Jul 3 2014, 2:10 PM
pawelo retitled this revision from to lldb - __arm64__ vs __aarch64__ insanity.
pawelo updated this object.
pawelo edited the test plan for this revision. (Show Details)
pawelo set the repository for this revision to rL LLVM.
pawelo added a subscriber: Unknown Object (MLST).
pawelo updated this revision to Diff 11138.Jul 7 2014, 8:43 PM
pawelo set the repository for this revision to rL LLVM.

RNBDefs.h changed as requested.

tfiala added a subscriber: tfiala.

Hey Paul,

Are you attempting to build debugserver over there on the linaro Linux build? If so, you will definitely find it easier going the lldb-gdbserver route (in fact I will be working on this as well). Apple will be moving over to lldb-gdbserver as well, so I think it will be wasted energy trying to get RNB* and debugserver files building over there. It's all way Apple-specific.

tfiala accepted this revision.Jul 8 2014, 6:26 PM
tfiala edited edge metadata.

Looks good. I'll check in shortly.

This revision is now accepted and ready to land.Jul 8 2014, 6:26 PM
tfiala closed this revision.Jul 8 2014, 6:37 PM

Sending source/Core/Error.cpp
Sending source/Host/common/Host.cpp
Sending source/Host/macosx/Host.mm
Sending source/Host/macosx/Symbols.cpp
Sending source/Interpreter/CommandInterpreter.cpp
Sending source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
Sending source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp
Sending source/Plugins/Platform/MacOSX/PlatformMacOSX.cpp
Sending source/Plugins/Process/Utility/RegisterContextDarwin_arm64.cpp
Sending source/Plugins/Process/Utility/RegisterContextMacOSXFrameBackchain.cpp
Sending source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
Sending source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
Sending test/functionalities/data-formatter/data-formatter-objc/main.m
Sending tools/debugserver/source/DNB.cpp
Sending tools/debugserver/source/DNBDefs.h
Sending tools/debugserver/source/MacOSX/MachThreadList.cpp
Sending tools/debugserver/source/MacOSX/arm/DNBArchImpl.cpp
Sending tools/debugserver/source/MacOSX/arm/DNBArchImpl.h
Sending tools/debugserver/source/MacOSX/arm64/DNBArchImplARM64.cpp
Sending tools/debugserver/source/MacOSX/arm64/DNBArchImplARM64.h
Sending tools/debugserver/source/RNBDefs.h
Sending tools/debugserver/source/RNBRemote.cpp
Transmitting file data ......................
Committed revision 212583.

pawelo added a comment.Jul 8 2014, 9:03 PM

Hey Todd,

That's the plan. This patch is a merely step towards this - it just clears
all the confusion caused by this double naming used by different
toolchains.