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 >
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
