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 <[email protected]> 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 <[email protected]> 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 < >> [email protected]> 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 <[email protected]> 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 <[email protected]> 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 < >>>>> [email protected]> 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 <[email protected]> >>>>>> 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 < >>>>>>> [email protected]> 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 < >>>>>>>> [email protected]> 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 <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> It comes from llvm/include/llvm/Support/MachO.h, line 1261. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Jul 23, 2014 at 9:57 AM, Keno Fischer < >>>>>>>>>> [email protected]> 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 <[email protected]> >>>>>>>>>>> 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 < >>>>>>>>>>>> [email protected]> 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 <[email protected] >>>>>>>>>>>>> > 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 < >>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>>>> [email protected]> 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 >>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Todd Fiala | Software Engineer | [email protected] | >>>>>>>>>>>>>>>>> 650-943-3180 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Todd Fiala | Software Engineer | [email protected] | >>>>>>>>>>>>>>> 650-943-3180 >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Todd Fiala | Software Engineer | [email protected] | >>>>>>>>>>>>>> 650-943-3180 >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Todd Fiala | Software Engineer | [email protected] | >>>>>>>>>>>> 650-943-3180 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Todd Fiala | Software Engineer | [email protected] | >>>>>>>>>> 650-943-3180 >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Todd Fiala | Software Engineer | [email protected] | 650-943-3180 >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Todd Fiala | Software Engineer | [email protected] | 650-943-3180 >>>>> >>>> >>>> >>>> >>>> -- >>>> Todd Fiala | Software Engineer | [email protected] | 650-943-3180 >>>> >>> >>> >> >> >> -- >> Todd Fiala | Software Engineer | [email protected] | 650-943-3180 >> > > > > -- > Todd Fiala | Software Engineer | [email protected] | 650-943-3180 >
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
