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