[Lldb-commits] [PATCH] lldb - __arm64__ vs __aarch64__ insanity

Todd Fiala tfiala at google.com
Mon Jul 7 14:53:47 PDT 2014


I expect in practice the places where we are going to need to differentiate
in aarch64/arm64 is really going to be along OS lines --- Apple's ABI is
different than what I think we use on other OSes (is that right, Greg?).
 But that's going to only matter in a few places I think, like stack
unwinding and other areas around determining which instruction set is
currently operating (thumb/arm/etc.) and possibly which registers get used
for what.

Paul, if you adjust that patch for what Greg indicated, I can give it a run
over here and verify all the normal Linux paths are still working.


On Mon, Jul 7, 2014 at 1:39 PM, Paul Osmialowski <pawelo at king.net.pl> wrote:

> Hi Greg,
>
> I really wasn't sure about this one. I looked through the code to see
> where RNB_ARCH is used and it seems like it's only for debugging purposes.
> In my view, it would be useful to distinguish how this platform
> architecture was recoginsed at compile time. However, as I said, I'm not
> sure about that, since I do realize that it may collide with some common
> policy.
>
> Cheers,
> Paul
>
>
> On Mon, 7 Jul 2014, Greg Clayton wrote:
>
>  Looks good except for "RNBRemote.cpp" which was:
>>
>> #elif defined (__aarch64__)
>>
>> #define RNB_ARCH    "aarch64"
>>
>> #elif defined (__arm64__)
>>
>> #define RNB_ARCH    "arm64"
>>
>> ...
>>
>> and should be:
>>
>>
>> #elif defined (__arm64__) || defined (__aarch64__)
>>
>> #define RNB_ARCH    "arm64"
>>
>> ...
>>
>>
>> We don't have any internal support for aarch64, so we should just pretend
>> it is "arm64" for now.
>>
>> Greg
>>
>>  On Jul 3, 2014, at 2:10 PM, Paul Osmialowski <pawelo at king.net.pl> wrote:
>>>
>>> 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.
>>>
>>> http://reviews.llvm.org/D4379
>>>
>>> Files:
>>>  source/Core/Error.cpp
>>>  source/Host/common/Host.cpp
>>>  source/Host/macosx/Host.mm
>>>  source/Host/macosx/Symbols.cpp
>>>  source/Interpreter/CommandInterpreter.cpp
>>>  source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
>>>  source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp
>>>  source/Plugins/Platform/MacOSX/PlatformMacOSX.cpp
>>>  source/Plugins/Process/Utility/RegisterContextDarwin_arm64.cpp
>>>  source/Plugins/Process/Utility/RegisterContextMacOSXFrameBackchain.cpp
>>>  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
>>>  source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
>>>  test/functionalities/data-formatter/data-formatter-objc/main.m
>>>  tools/debugserver/source/DNB.cpp
>>>  tools/debugserver/source/DNBDefs.h
>>>  tools/debugserver/source/MacOSX/MachThreadList.cpp
>>>  tools/debugserver/source/MacOSX/arm/DNBArchImpl.cpp
>>>  tools/debugserver/source/MacOSX/arm/DNBArchImpl.h
>>>  tools/debugserver/source/MacOSX/arm64/DNBArchImplARM64.cpp
>>>  tools/debugserver/source/MacOSX/arm64/DNBArchImplARM64.h
>>>  tools/debugserver/source/RNBDefs.h
>>>  tools/debugserver/source/RNBRemote.cpp
>>> <D4379.11066.patch>_______________________________________________
>>> lldb-commits mailing list
>>> lldb-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
>>>
>>
>>  _______________________________________________
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
>



-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20140707/2a92bf22/attachment.html>


More information about the lldb-commits mailing list