[lldb-dev] Building lldb on OS X

Keno Fischer kfischer at college.harvard.edu
Wed Jul 23 10:51:53 PDT 2014 

On 10.9.4, my /usr/include/mach/machine.h does not include that constant.


On Wed, Jul 23, 2014 at 10:48 AM, Todd Fiala <tfiala at google.com> wrote:

> Okay - so this patch won’t work on MacOSX Xcode builds - it starts picking
> up the wrong definition of that symbol (from machine.h):
>
> Index: source/Host/common/Host.cpp
> ===================================================================
> --- source/Host/common/Host.cpp    (revision 213770)
> +++ source/Host/common/Host.cpp    (working copy)
> @@ -32,6 +32,8 @@
>  #include <sys/sysctl.h>
>  #endif
>
> +#include "lldb/Utility/SafeMachO.h"
> +
>  #if defined (__APPLE__)
>  #include <mach/mach_port.h>
>  #include <mach/mach_init.h>
> @@ -368,7 +370,7 @@
>                  // Now we need modify the cpusubtype for the 32 bit slices.
>                  uint32_t cpusubtype32 = cpusubtype;
>  #if defined (__i386__) || defined (__x86_64__)
> -                if (cpusubtype == CPU_SUBTYPE_486 || cpusubtype == CPU_SUBTYPE_X86_64_H)
> +                if (cpusubtype == CPU_SUBTYPE_486 || cpusubtype == llvm::MachO::CPU_SUBTYPE_X86_64_H)
>                      cpusubtype32 = CPU_SUBTYPE_I386_ALL;
>  #elif defined (__arm__) || defined (__arm64__) || defined (__aarch64__)
>                  if (cputype == CPU_TYPE_ARM || cputype == CPU_TYPE_ARM64)
>
> It is picking up this definition:
>
> #define CPU_SUBTYPE_X86_64_H        ((cpu_subtype_t)8)    /* Haswell feature subset */
>
> from /usr/include/mach/machine.h.
>
> I think the path we’ll want to figure out is how to adjust the makefile
> include paths to better match the Xcode build.
>
> I can probably dump out a compile execution of that file in Xcode the
> figure out what specifically it is using, in which case you can see how the
> Makefile is building the include path and perhaps adjust that properly for
> MacOSX?
>
> -Todd
> ​
>
>
> On Wed, Jul 23, 2014 at 10:37 AM, Todd Fiala <tfiala at google.com> wrote:
>
>> No problem, just wanted to make sure I'm using the code you intended :-)
>>  Thanks!
>>
>>
>> On Wed, Jul 23, 2014 at 10:34 AM, Keno Fischer <
>> kfischer at college.harvard.edu> wrote:
>>
>>> Sorry, yeah it got truncated, basically just prepend llvm::MachO:: to CPU_SUBTYPE_X86_64_H.
>>> Sorry about that.
>>>
>>>
>>> On Wed, Jul 23, 2014 at 10:32 AM, Todd Fiala <tfiala at google.com> wrote:
>>>
>>>> Hm is the patch here what you really wanted?  It might be getting
>>>> truncated?
>>>>
>>>> -                if (cpusubtype == CPU_SUBTYPE_486 || cpusubtype ==
>>>> CPU_SUBTYPE_
>>>> +                if (cpusubtype == CPU_SUBTYPE_486 || cpusubtype ==
>>>> llvm::MachO:
>>>>
>>>> Seems incomplete.
>>>>
>>>>
>>>> On Wed, Jul 23, 2014 at 10:24 AM, Todd Fiala <tfiala at google.com> wrote:
>>>>
>>>>> I'll go ahead and give it a run on Xcode.  If it doesn't break
>>>>> anything there, sure I'll go ahead and commit it.
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Jul 23, 2014 at 10:22 AM, Keno Fischer <
>>>>> kfischer at college.harvard.edu> wrote:
>>>>>
>>>>>> Does the Xcode build automatically include SafeMachO.h? Also, any
>>>>>> harm in just committing that patch, if not would you mind doing that (I
>>>>>> don't have commit access)?
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 23, 2014 at 10:17 AM, Todd Fiala <tfiala at google.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Ok.  Sounds like there are header ordering differences between
>>>>>>> configure/make and the Xcode build.  That might be causing issues.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jul 23, 2014 at 10:14 AM, Keno Fischer <
>>>>>>> kfischer at college.harvard.edu> wrote:
>>>>>>>
>>>>>>>> Ok, figured it out. The position of the SafeMachO.h header matters.
>>>>>>>> This works:
>>>>>>>>
>>>>>>>> ```
>>>>>>>> diff --git a/source/Host/common/Host.cpp
>>>>>>>> b/source/Host/common/Host.cpp
>>>>>>>> index 275b446..3802224 100644
>>>>>>>> --- a/source/Host/common/Host.cpp
>>>>>>>> +++ b/source/Host/common/Host.cpp
>>>>>>>> @@ -32,6 +32,8 @@
>>>>>>>>  #include <sys/sysctl.h>
>>>>>>>>  #endif
>>>>>>>>
>>>>>>>> +#include "lldb/Utility/SafeMachO.h"
>>>>>>>> +
>>>>>>>>  #if defined (__APPLE__)
>>>>>>>>  #include <mach/mach_port.h>
>>>>>>>>  #include <mach/mach_init.h>
>>>>>>>> @@ -368,7 +370,7 @@ Host::GetArchitecture
>>>>>>>> (SystemDefaultArchitecture arch_kind)
>>>>>>>>                  // Now we need modify the cpusubtype for the 32
>>>>>>>> bit slices.
>>>>>>>>                  uint32_t cpusubtype32 = cpusubtype;
>>>>>>>>  #if defined (__i386__) || defined (__x86_64__)
>>>>>>>> -                if (cpusubtype == CPU_SUBTYPE_486 || cpusubtype ==
>>>>>>>> CPU_SUBTYPE_
>>>>>>>> +                if (cpusubtype == CPU_SUBTYPE_486 || cpusubtype ==
>>>>>>>> llvm::MachO:
>>>>>>>>                      cpusubtype32 = CPU_SUBTYPE_I386_ALL;
>>>>>>>>  #elif defined (__arm__) || defined (__arm64__) || defined
>>>>>>>> (__aarch64__)
>>>>>>>>                  if (cputype == CPU_TYPE_ARM || cputype ==
>>>>>>>> CPU_TYPE_ARM64)
>>>>>>>> ```
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jul 23, 2014 at 10:04 AM, Keno Fischer <
>>>>>>>> kfischer at college.harvard.edu> wrote:
>>>>>>>>
>>>>>>>>> I don't think that file is included from Host.cpp or am I missing
>>>>>>>>> something?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Jul 23, 2014 at 9:59 AM, Todd Fiala <tfiala at google.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> It comes from llvm/include/llvm/Support/MachO.h, line 1261.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Jul 23, 2014 at 9:57 AM, Keno Fischer <
>>>>>>>>>> kfischer at college.harvard.edu> wrote:
>>>>>>>>>>
>>>>>>>>>>> Through which path is that constant supposed to be defined? I
>>>>>>>>>>> can check that all those are picked up correctly.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Jul 23, 2014 at 9:55 AM, Todd Fiala <tfiala at google.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Ok.  Definitely sounds worth of opening up a llvm.org/bugs
>>>>>>>>>>>> ticket on.  That way you can attach your make logs and whatnot.
>>>>>>>>>>>>
>>>>>>>>>>>> Based on what you reported so far, it sounds like perhaps the
>>>>>>>>>>>> build is picking up headers from the wrong place (i.e. maybe configure is
>>>>>>>>>>>> finding the wrong llvm code, or something that is causing headers from one
>>>>>>>>>>>> place to get used with code from another, perhaps between the local lldb
>>>>>>>>>>>> and llvm/clang code).
>>>>>>>>>>>>
>>>>>>>>>>>> -Todd
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Jul 23, 2014 at 9:51 AM, Keno Fischer <
>>>>>>>>>>>> kfischer at college.harvard.edu> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> That's not really a great option, because it means I have to
>>>>>>>>>>>>> maintain three build systems on my side with three different
>>>>>>>>>>>>> configurations, especially because the rest of llvm/clang builds just fine
>>>>>>>>>>>>> with Makefiles. I will track down why this fails and submit a patch. Since
>>>>>>>>>>>>> this is the only issue preventing a clean build of lldb with Makefiles, I
>>>>>>>>>>>>> think that will be significantly less work than adjusting the rest of the
>>>>>>>>>>>>> pipeline to work with three build systems.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 9:26 AM, Todd Fiala <tfiala at google.com
>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ok I did an Xcode and Ubuntu 14.04 build at llvm, clang and
>>>>>>>>>>>>>> lldb r213767 (just a few minutes ago), and those all worked.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Are you in a position where you can use the Xcode build on
>>>>>>>>>>>>>> MacOSX?  If so, that's definitely the way to go.  cmake gets little
>>>>>>>>>>>>>> attention there, and frankly I didn't even know the configure/make build on
>>>>>>>>>>>>>> MacOSX even worked.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> At the moment we're struggling with having 3 build systems.
>>>>>>>>>>>>>>  At best we're maintaining the canonical build system for a given platform.
>>>>>>>>>>>>>>  Right now that seems to be Xcode for MacOSX, cmake for Ubuntu and FreeBSD.
>>>>>>>>>>>>>>  make/configure seems to be used by Debian's 'build (maybe FC too?).  I
>>>>>>>>>>>>>> would recommend attempting to use the canonical build system for lldb on a
>>>>>>>>>>>>>> given platform to minimize difficulties since those will tend to get fixed
>>>>>>>>>>>>>> quickly when they do break on the given platform.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 9:13 AM, Todd Fiala <
>>>>>>>>>>>>>> tfiala at google.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ah shucks, ok.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I did fix a build issue that occurred this morning due to
>>>>>>>>>>>>>>> some changes in llvm, but I don't think I hit that one.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'll do a quick sync now just to see if maybe that crept in
>>>>>>>>>>>>>>> over the last hour or two since I came in.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -Todd
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 9:11 AM, Keno Fischer <
>>>>>>>>>>>>>>> kfischer at college.harvard.edu> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No, I'm doing a Makefile build. LLVM/Clang/LLDB are all at
>>>>>>>>>>>>>>>> latest trunk.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 9:06 AM, Todd Fiala <
>>>>>>>>>>>>>>>> tfiala at google.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hey Keno!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Are you doing an Xcode build?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If so, you may be suffering from what I did when I first
>>>>>>>>>>>>>>>>> started using Xcode builds.  Xcode puts the llvm and llvm/tools/clang
>>>>>>>>>>>>>>>>> directory underneath the lldb directory.  It does a sync the first time for
>>>>>>>>>>>>>>>>> you, but not after that.  So, you may be dealing with an llvm and clang
>>>>>>>>>>>>>>>>> tree that are out of date with respect to your version of llvm.  If that's
>>>>>>>>>>>>>>>>> the case, just do this:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> cd /your/lldb/path
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> cd llvm
>>>>>>>>>>>>>>>>> svn update
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> cd tools/clang
>>>>>>>>>>>>>>>>> svn update
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> # Put you back in the lldb dir
>>>>>>>>>>>>>>>>> cd ../../..
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Then redo your build of lldb.  It will run the auto
>>>>>>>>>>>>>>>>> llvm/clang build step (somewhat long), then get back to building lldb.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Let me know if that solves your issue!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -Todd
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 8:43 AM, Keno Fischer <
>>>>>>>>>>>>>>>>> kfischer at college.harvard.edu> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> While building on OS X I have been sent reports of the
>>>>>>>>>>>>>>>>>> following (I
>>>>>>>>>>>>>>>>>> did see it myself at one point as well, but worked around
>>>>>>>>>>>>>>>>>> it). I tried
>>>>>>>>>>>>>>>>>> including SafeMachO.h but that caused other problems in
>>>>>>>>>>>>>>>>>> the llvm
>>>>>>>>>>>>>>>>>> headers. What's the proper way to get around this other
>>>>>>>>>>>>>>>>>> than `#define
>>>>>>>>>>>>>>>>>> CPU_SUBTYPE_X86_64_H 8`?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> lldb/source/Host/common/Host.cpp:371:68: error: use of
>>>>>>>>>>>>>>>>>> undeclared
>>>>>>>>>>>>>>>>>> identifier 'CPU_SUBTYPE_X86_64_H'
>>>>>>>>>>>>>>>>>>                 if (cpusubtype == CPU_SUBTYPE_486 ||
>>>>>>>>>>>>>>>>>> cpusubtype ==
>>>>>>>>>>>>>>>>>> CPU_SUBTYPE_X86_64_H)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Keno
>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>> lldb-dev mailing list
>>>>>>>>>>>>>>>>>> lldb-dev at cs.uiuc.edu
>>>>>>>>>>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>  Todd Fiala | Software Engineer |  tfiala at google.com |
>>>>>>>>>>>>>>>>> 650-943-3180
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Todd Fiala | Software Engineer |  tfiala at google.com |
>>>>>>>>>>>>>>> 650-943-3180
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Todd Fiala | Software Engineer |  tfiala at google.com |
>>>>>>>>>>>>>> 650-943-3180
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Todd Fiala | Software Engineer |  tfiala at google.com |
>>>>>>>>>>>> 650-943-3180
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Todd Fiala | Software Engineer |  tfiala at google.com |
>>>>>>>>>> 650-943-3180
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Todd Fiala | Software Engineer |  tfiala at google.com |  650-943-3180
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Todd Fiala | Software Engineer |  tfiala at google.com |  650-943-3180
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Todd Fiala | Software Engineer |  tfiala at google.com |  650-943-3180
>>>>
>>>
>>>
>>
>>
>> --
>> Todd Fiala | Software Engineer |  tfiala at google.com |  650-943-3180
>>
>
>
>
> --
> 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-dev/attachments/20140723/6660bebe/attachment.html>

More information about the lldb-dev mailing list