Xcode builds

Hey guys,

I’m getting errors like this on lldb TOT building within Xcode:

CompileC /Users/tfiala/Library/Developer/Xcode/DerivedData/lldb-fdedbkfqiftsgoaeqxdcrpiwguzs/Build/Intermediates/lldb.build/Debug/lldb-core.build/Objects-normal/x86_64/ArchSpec.o source/Core/ArchSpec.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler

cd /Users/tfiala/lldb/svn/llvm/tools/lldb

export LANG=en_US.US-ASCII

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x c++ -arch x86_64 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -std=c++11 -stdlib=libc++ -Wno-trigraphs -fpascal-strings -O0 -Wmissing-field-initializers -Wno-missing-prototypes -Wnon-virtual-dtor -Woverloaded-virtual -Wno-exit-time-destructors -Wmissing-braces -Wparentheses -Wswitch -Wno-unused-function -Wunused-label -Wno-unused-parameter -Wunused-variable -Wunused-value -Wempty-body -Wuninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wconstant-conversion -Wint-conversion -Wno-bool-conversion -Wenum-conversion -Wno-shorten-64-to-32 -Wnewline-eof -Wno-c++11-extensions -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -DLLDB_CONFIGURATION_DEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -fasm-blocks -fstrict-aliasing -Wdeprecated-declarations -Winvalid-offsetof -mmacosx-version-min=10.7 -g -Wno-sign-conversion -iquote /Users/tfiala/Library/Developer/Xcode/DerivedData/lldb-fdedbkfqiftsgoaeqxdcrpiwguzs/Build/Intermediates/lldb.build/Debug/lldb-core.build/liblldb-core-generated-files.hmap -I/Users/tfiala/Library/Developer/Xcode/DerivedData/lldb-fdedbkfqiftsgoaeqxdcrpiwguzs/Build/Intermediates/lldb.build/Debug/lldb-core.build/liblldb-core-own-target-headers.hmap -I/Users/tfiala/Library/Developer/Xcode/DerivedData/lldb-fdedbkfqiftsgoaeqxdcrpiwguzs/Build/Intermediates/lldb.build/Debug/lldb-core.build/liblldb-core-all-target-headers.hmap -iquote /Users/tfiala/Library/Developer/Xcode/DerivedData/lldb-fdedbkfqiftsgoaeqxdcrpiwguzs/Build/Intermediates/lldb.build/Debug/lldb-core.build/liblldb-core-project-headers.hmap -iquote/Users/tfiala/lldb/svn/llvm/tools/lldb/include -iquote/Users/tfiala/lldb/svn/llvm/tools/lldb/source -iquote/Users/tfiala/lldb/svn/llvm/tools/lldb/llvm/include -iquote/Users/tfiala/lldb/svn/llvm/tools/lldb/llvm/tools/clang/include -iquote/Users/tfiala/lldb/svn/llvm/tools/lldb/llvm-build/Release+Asserts/x86_64/include -iquote/Users/tfiala/lldb/svn/llvm/tools/lldb/llvm-build/Release+Asserts/x86_64/tools/clang/include -I/Users/tfiala/Library/Developer/Xcode/DerivedData/lldb-fdedbkfqiftsgoaeqxdcrpiwguzs/Build/Products/Debug/include -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/libxml2 -I/Users/tfiala/Library/Developer/Xcode/DerivedData/lldb-fdedbkfqiftsgoaeqxdcrpiwguzs/Build/Intermediates/lldb.build/Debug/lldb-core.build/DerivedSources/x86_64 -I/Users/tfiala/Library/Developer/Xcode/DerivedData/lldb-fdedbkfqiftsgoaeqxdcrpiwguzs/Build/Intermediates/lldb.build/Debug/lldb-core.build/DerivedSources -Wreorder -F/Users/tfiala/Library/Developer/Xcode/DerivedData/lldb-fdedbkfqiftsgoaeqxdcrpiwguzs/Build/Products/Debug -F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/PrivateFrameworks -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -fno-rtti -Wglobal-constructors -flimit-debug-info -Wparentheses -DLLDB_USE_BUILTIN_DEMANGLER -MMD -MT dependencies -MF /Users/tfiala/Library/Developer/Xcode/DerivedData/lldb-fdedbkfqiftsgoaeqxdcrpiwguzs/Build/Intermediates/lldb.build/Debug/lldb-core.build/Objects-normal/x86_64/ArchSpec.d --serialize-diagnostics /Users/tfiala/Library/Developer/Xcode/DerivedData/lldb-fdedbkfqiftsgoaeqxdcrpiwguzs/Build/Intermediates/lldb.build/Debug/lldb-core.build/Objects-normal/x86_64/ArchSpec.dia -c /Users/tfiala/lldb/svn/llvm/tools/lldb/source/Core/ArchSpec.cpp -o /Users/tfiala/Library/Developer/Xcode/DerivedData/lldb-fdedbkfqiftsgoaeqxdcrpiwguzs/Build/Intermediates/lldb.build/Debug/lldb-core.build/Objects-normal/x86_64/ArchSpec.o

/Users/tfiala/lldb/svn/llvm/tools/lldb/source/Core/ArchSpec.cpp:79:48: error: no member named ‘arm64’ in ‘llvm::Triple’

{ eByteOrderLittle, 8, 4, 4, llvm::Triple::arm64 , ArchSpec::eCore_arm_arm64 , “arm64” },


/Users/tfiala/lldb/svn/llvm/tools/lldb/source/Core/ArchSpec.cpp:184:54: error: no member named 'CPU_TYPE_ARM64' in namespace 'llvm::MachO'; did you mean 'CPU_TYPE_ARM'?

{ ArchSpec::eCore_arm_arm64 , llvm::MachO::CPU_TYPE_ARM64 , CPU_ANY, UINT32_MAX , SUBTYPE_MASK },

~~~~~~~~~~~~~^~~~~~~~~~~~~~

CPU_TYPE_ARM

In file included from /Users/tfiala/lldb/svn/llvm/tools/lldb/source/Core/ArchSpec.cpp:20:

In file included from /Users/tfiala/lldb/svn/llvm/tools/lldb/include/lldb/Utility/SafeMachO.h:111:

/Users/tfiala/lldb/svn/llvm/tools/lldb/llvm/include/llvm/Support/MachO.h:914:7: note: 'CPU_TYPE_ARM' declared here

CPU_TYPE_ARM = 12,

^

/Users/tfiala/lldb/svn/llvm/tools/lldb/source/Core/ArchSpec.cpp:185:54: error: no member named 'CPU_TYPE_ARM64' in namespace 'llvm::MachO'; did you mean 'CPU_TYPE_ARM'?

{ ArchSpec::eCore_arm_arm64 , llvm::MachO::CPU_TYPE_ARM64 , 0 , UINT32_MAX , SUBTYPE_MASK },

~~~~~~~~~~~~~^~~~~~~~~~~~~~

CPU_TYPE_ARM

In file included from /Users/tfiala/lldb/svn/llvm/tools/lldb/source/Core/ArchSpec.cpp:20:

In file included from /Users/tfiala/lldb/svn/llvm/tools/lldb/include/lldb/Utility/SafeMachO.h:111:

/Users/tfiala/lldb/svn/llvm/tools/lldb/llvm/include/llvm/Support/MachO.h:914:7: note: 'CPU_TYPE_ARM' declared here

CPU_TYPE_ARM = 12,

^

/Users/tfiala/lldb/svn/llvm/tools/lldb/source/Core/ArchSpec.cpp:186:54: error: no member named 'CPU_TYPE_ARM64' in namespace 'llvm::MachO'; did you mean 'CPU_TYPE_ARM'?

{ ArchSpec::eCore_arm_arm64 , llvm::MachO::CPU_TYPE_ARM64 , 1 , UINT32_MAX , SUBTYPE_MASK },

~~~~~~~~~~~~~^~~~~~~~~~~~~~

CPU_TYPE_ARM

In file included from /Users/tfiala/lldb/svn/llvm/tools/lldb/source/Core/ArchSpec.cpp:20:

In file included from /Users/tfiala/lldb/svn/llvm/tools/lldb/include/lldb/Utility/SafeMachO.h:111:

/Users/tfiala/lldb/svn/llvm/tools/lldb/llvm/include/llvm/Support/MachO.h:914:7: note: 'CPU_TYPE_ARM' declared here

CPU_TYPE_ARM = 12,

^

/Users/tfiala/lldb/svn/llvm/tools/lldb/source/Core/ArchSpec.cpp:187:54: error: no member named 'CPU_TYPE_ARM64' in namespace 'llvm::MachO'; did you mean 'CPU_TYPE_ARM'?

{ ArchSpec::eCore_arm_arm64 , llvm::MachO::CPU_TYPE_ARM64 , 13 , UINT32_MAX , SUBTYPE_MASK },

~~~~~~~~~~~~~^~~~~~~~~~~~~~

CPU_TYPE_ARM

In file included from /Users/tfiala/lldb/svn/llvm/tools/lldb/source/Core/ArchSpec.cpp:20:

In file included from /Users/tfiala/lldb/svn/llvm/tools/lldb/include/lldb/Utility/SafeMachO.h:111:

/Users/tfiala/lldb/svn/llvm/tools/lldb/llvm/include/llvm/Support/MachO.h:914:7: note: 'CPU_TYPE_ARM' declared here

CPU_TYPE_ARM = 12,

^

/Users/tfiala/lldb/svn/llvm/tools/lldb/source/Core/ArchSpec.cpp:738:44: error: no member named 'arm64' in 'llvm::Triple'

case llvm::Triple::arm64:

~~~~~~~~~~~~~~^

6 errors generated.

I’ve gone back to start of yesterday and still see it. I’ve wiped my DerivedData directories. Do I have something misconfigured in Xcode or is this a valid build break?

From my end it looks like the arm64 part should be aarch64 (?), but the other failures around CPU_TYPE_ARM64 was less clear what to do.

Thanks!

Hi Todd,

From my end it looks like the arm64 part should be aarch64 (?), but the
other failures around CPU_TYPE_ARM64 was less clear what to do.

The situation's in flux, but at the moment both ARM64 and AArch64
exist in ToT. If I had to guess at your errors, I'd say you hadn't
updated the llvm tree in a while so it's out of sync with lldb.
Certainly CPU_TYPE_ARM is no longer defined on line 914 of MachO.h.

So have you updated llvm (& clang)?

Cheers.

Tim.

Thanks, Tim.

Yeah, sorry I wasn’t more clear when I said I moved between yesterday and today. I meant I synched to start of yesterday llvm and clang svn repos after top of tree across all 3 repos wasn’t working.

So - current state is:
top of tree - lldb, llvm and clang repos.

Specific versions:
llvm - svn r207854
clang - svn r207854
lldb - svn r207854

This is off a fresh clean/sync/build from a minute ago.

FWIW this is building fine on Linux. I only noticed when I was testing a patch that I want to verify on OS X (some debugserver testing).

-Todd

Looks like you are getting a conflict with the macros defined in:

<mach/machine.h>

and these are ruining the defines set in:

"llvm/Support/MachO.h"

So you aren't missing anything and I am not sure why things are different for us. I thought this was fixed by adding an underscore in front of all CPU_TYPE_XXX items in MachO.h that exactly matched macros in machine.h... It is really lame that a header file in LLVM is using macros that exactly match enums.

You might be able to fix it by #including the "llvm/Support/MachO.h" first in the file before any other files.

Thanks, Greg. I’ll give that a shot!

I tried adjusting the ArchSpec.cpp headers like so:

//===-- ArchSpec.cpp --------------------------------------------- C++ --===//

//

// The LLVM Compiler Infrastructure

//

// This file is distributed under the University of Illinois Open Source

// License. See LICENSE.TXT for details.

//

//===----------------------------------------------------------------------===//

// 1. tfiala added this one here

#include “llvm/Support/MachO.h”

#include “lldb/Core/ArchSpec.h”

#include <stdio.h>

#include <errno.h>

#include

#include “llvm/Support/COFF.h”

#include “llvm/Support/ELF.h”

#include “llvm/Support/Host.h”

// 3. tfiala also tried commenting out below

#include “lldb/Utility/SafeMachO.h”
// 2. tfiala added this one here
#include “llvm/Support/MachO.h”

#include “lldb/Core/RegularExpression.h”

#include “lldb/Host/Endian.h”

#include “lldb/Host/Host.h”

#include “lldb/Target/Platform.h”

At first I just added the element at (1.) above. That gave me the same error as before. I then added it after the SafeMachO.h include at (2.) above while keeping (1.) in, just in case SafeMachO.h was pulling in something that wasn’t . That didn’t work either. Finally I tried commenting out (3.) just in case that was doing something that failed. That gave me different errors and was clearly wrong.

Any other ideas?

-Todd

Feature, not a bug. IMO it's lame that <mach/machine.h> uses macros
instead of enums. :wink:

Is <mach/machine.h> pulled in transitively, or is it an explicit include?
If so, what's being used? Can it be isolated to a single cpp file?

I would try to stop <mach/machine.h> from being included.

Looks like you are getting a conflict with the macros defined in:

<mach/machine.h>

and these are ruining the defines set in:

"llvm/Support/MachO.h"

So you aren't missing anything and I am not sure why things are different for us. I thought this was fixed by adding an underscore in front of all CPU_TYPE_XXX items in MachO.h that exactly matched macros in machine.h... It is really lame that a header file in LLVM is using macros that exactly match enums.

Feature, not a bug. IMO it's lame that <mach/machine.h> uses macros instead of enums. :wink:

I completely agree, but alas we are stuck with this on MacOSX.

Is <mach/machine.h> pulled in transitively, or is it an explicit include? If so, what's being used? Can it be isolated to a single cpp file?

No one should be including it manually as we shouldn't have ANY code depending on platform specific headers. Try preprocessing your file and see who includes machine.h.

No one should be including it manually as we shouldn’t have ANY code depending on platform specific headers. Try preprocessing your file and see who includes machine.h.

Will do.

Attached is my preprocessed ArchSpec.cpp from llvm/clang/lldb all synched to TOT from a few moments ago (r207938). I’m using Xcode Version 5.1 (5B130a).

I’m not seeing it pick up machine.h in the output. The first time I see MACHINE_TYPE_* is from llvm/Support/MachO.

Note this file doesn’t have any local changes in it.

ArchSpec.preprocessed.cpp.bz2 (192 KB)

(And it is still getting all the same errors as I reported on Friday).

An email got held up in the middle there since the bzip2’d preprocessed header was too large to pass the 128k filter for the list.

Short answer: somehow the directory scheme used by my Xcode build is using an llvm embedded within the lldb directory, way different than what I use on all other builds (where I have llvm at the top level, tools/clang and tools/lldb as children thereof). My build issue is a non-issue: my llvm and clang directories were getting sourced from an unexpected location and those were stale. I will figure out how that happened later.

Thanks!

-Todd